Theory
An event, as a document
In MongoDB, FestConnect's Garba Night is not a row in a table: it is a document, a JSON-like object you can almost read aloud:
{ name: "Garba Night", seats: 350, online: false, tags: ["cultural", "dance"] }
A name (string), seats (number), online (boolean), tags (an array): each field carries its own type, and the whole thing looks exactly like the JavaScript objects from BCA405-01. This lesson covers the data TYPES a document can hold, and how to create and drop the DATABASE that stores them. First, the vocabulary: databases hold collections, collections hold documents.
Theory
MongoDB's structure and types
MongoDB nests 3 levels: a database holds collections, and a collection holds documents (the individual records).
A document's fields can be these types:
- String:
"Garba Night" - Integer and Double: whole numbers and decimals (
350,49.5) - Boolean:
true/false - Array: a field holding a list (
["cultural", "dance"]) - Object (embedded document): a field holding ANOTHER document
- plus ObjectId (the automatic unique
_id), Date, and Null
That embedded-object ability is powerful: an event's venue can be a whole sub-document inside the event, no join needed.
Practical
A FestConnect event document (every type)
// A single MongoDB document for one event:
{
name: "Garba Night", // String
seats: 350, // Integer
fee: 49.5, // Double
online: false, // Boolean
tags: ["cultural", "dance"], // Array
venue: { // Object (embedded document)
hall: "Main Ground",
capacity: 400
}
// _id: an ObjectId is added automatically if you do not supply one
}
// The venue is embedded INSIDE the event: no separate table, no join.
This example runs in Gri-Learn on the web, where you can edit it and see the output.
Theory
Creating and dropping a database
In the mongo shell, you work with a database using these commands:
- `use festdb`: switch to the
festdbdatabase, creating it LAZILY. Crucial nuance: the database is NOT actually written to disk until you insert data into it.useon a brand-new name just points you at it - `show dbs`: list existing databases (a lazily-created empty one will not appear yet)
- `db.dropDatabase()`: delete the CURRENT database entirely
The lazy creation surprises beginners: they use newdb, run show dbs, and do not see it, thinking it failed. It did not: the database materialises the moment the first document lands in it.
Quiz
You run `use festdb` on a database name that does not exist yet, then `show dbs`, and festdb is NOT listed. Why?
- The use command failed
- MongoDB creates databases LAZILY: festdb is not written to disk until you insert data, so it does not appear in show dbs until then
- You must run createDatabase() first
- Database names cannot contain letters
Show the answer
MongoDB creates databases LAZILY: festdb is not written to disk until you insert data, so it does not appear in show dbs until then
MongoDB creates databases (and collections) LAZILY: use festdb switches your context to festdb and prepares it, but it is not persisted or listed until the first document is inserted. So show dbs not listing an empty, freshly-used database is expected, not an error. Option A misreads normal behaviour as failure. Option C invents a command: there is no createDatabase(); use plus an insert is how a database comes into being. Option D is false. The rule to remember: use points you at a database (creating it lazily), and it truly exists once data is in it.
Think first
Embedded object or separate collection?
FestConnect's event has a venue with a hall name and capacity. You could embed the venue inside the event document, or store venues in a separate collection. When does embedding win? Then tap.
Show the answer
EMBED the venue inside the event when the venue data BELONGS to that event and is accessed together with it: which is usually the case here. Embedding means one document read gets the event AND its venue, with no join: fast and simple, and it fits MongoDB's document model. You would instead use a SEPARATE collection when the same venue is SHARED across many events and you want to update it in one place (avoiding duplicating venue details in every event), or when venue data is large and rarely needed. This embed-vs-reference decision is MongoDB's version of the normalise-vs-denormalise trade-off: embed for data accessed together and owned by the parent, reference for shared or independently-changing data.
Watch out
MongoDB basics traps
Expecting an empty database to appear: use creates lazily; the db shows up only after data is inserted.
Looking for createDatabase(): there is none; use + insert creates it.
Forgetting the automatic _id: every document gets a unique ObjectId _id unless you supply your own.
dropDatabase() drops the CURRENT db: make sure you are on the right one (check with db) before dropping: it is irreversible.
Confusing database, collection, document: database contains collections contain documents (records).
Theory
Database ready; now collections
You can model an event as a typed document and create or drop the festdb database. Documents live inside COLLECTIONS (the rough equivalent of tables), so the next short lesson covers creating and dropping collections, before the heart of the unit: CRUD operations (insert, find, update, delete) and the query and projection operators that make MongoDB genuinely useful for FestConnect.
Summary
Key takeaways
- MongoDB structure: a database holds collections, a collection holds documents (JSON-like records).
- Document field types: String, Integer, Double, Boolean, Array, Object (embedded document), plus ObjectId, Date, Null.
- Embedded objects let related data (a venue) sit inside a document: no join needed.
- Every document gets an automatic unique _id (an ObjectId) unless you supply one.
- use dbname switches to (and lazily creates) a database; it is not persisted until data is inserted.
- db.dropDatabase() deletes the current database (irreversible: check you are on the right one).
- Memory hook: documents are JSON with types; use creates lazily, data makes it real.