The computer/program doesn’t know anything you don’t explain. Neither do your coworkers. So, as simple as it sounds – you 100% have to define everything (explicitly).

It’s fun. You are the creator. What are you going to create?

Concept: At the most basic level, data is stored as individual records. You can retrieve either a single record by its unique ID or a complete list of records.

Document-Based: Each record is stored as a document in a collection (e.g., a monster document in a monsters collection).

Table-Based: Each record is stored as a row in a table (e.g., a monster in a monsters table).

Question: But where? (also – we should probably add a note about schema and how these columns have specific datatypes set)

To start, you can manually write out this data. But pretty quickly, you’re going to want to build out some forms so that users can start adding their own data and test the app.

English: Add a new monster named “Bruno,” aged 150, not adopted yet.

SQL:
INSERT INTO monsters (name, age, adopted)
VALUES ('Bruno', 150, false);

Doc: db.monsters.insertOne({ name: 'Bruno', age: 150, adopted: false });

And you might realize that there is no Bruno! And you need to update the record. Or that there is a Bruno – but you didn’t know because they got adopted already.

English: Update Bruno’s adoption status

SQL:
UPDATE monsters
SET adopted = true
WHERE id = 4; -- Using Bruno's ID

Doc: db.monsters.updateOne({ id: 4 }, { $set: { adopted: true } });

Or maybe it turned out Bruno was all in your imagination, and you need to delete that record.

English: Remove Bruno

SQL:
DELETE FROM monsters
WHERE id = 4;

Doc: db.monsters.deleteOne({ id: 4 });

But maybe… you don’t really want to fully “delete” it and instead do some form of “soft delete.”

English: Mark Bruno as “archived” so we can recover his record later if needed

SQL:
ALTER TABLE monsters ADD archived BOOLEAN DEFAULT false;
UPDATE monsters
SET archived = true
WHERE id = 4;

Doc: db.monsters.updateOne({ id: 4 }, { $set: { archived: true } });

Concept: Data is typically retrieved from files or databases. The process will vary depending on your environment, but the goal remains consistent—access and manipulate your data, whether it’s stored in a local file, a database, or even a global variable.

Let’s assume data like database.monsters is already available globally in our examples. Focus on the concepts rather than the specific syntax or how the data is retrieved.

English: I'd love a list of all the monsters, please

SQL: SELECT * FROM monsters;

Doc: db.monsters.find({});

Concept: Once the data is retrieved, the next step is often rendering it on a page, typically in a list format. Each item will have a link to its corresponding detail page, allowing users to explore more information.

(Just to remind you of what you’ll likely do with the data)

You’re probably going to have a list page where you display products, cars, teams, or monsters. This list acts as an index, allowing users to click and request individual detail pages for specific items. Each page will show more detailed information about a single record.

Concept: When working with your data, you’ll often need to retrieve one specific record, typically based on an ID or uuid or slug. Whether you’re working with an array in PHP, JavaScript, or querying a database, the approach remains consistent—find the unique record by its identifier.

After listing all records, you’ll likely want a detail page for each item. When a user clicks a monster on the list page, they expect to see more details about that specific monster. The way we retrieve that single record in PHP or JavaScript is very similar. And there are convenience functions like array_search() and array.find()

English: I want to see the details for just one monster—here’s the ID

SQL: SELECT * FROM monsters WHERE id = 1;

Doc: db.monsters.findOne({ id: 1 });

Concept: Filtering records lets you pull out data that meets certain conditions (like finding all monsters that haven’t been adopted yet). It’s key for narrowing down big datasets to just the stuff you care about.

If you already have all the data, you can sort it yourself. But if you’re asking for sorted data, the server will take care of that before sending it back to you.

English: Show me all the monsters that haven’t been adopted yet.

SQL: SELECT * FROM monsters WHERE adopted = false;

Doc: db.monsters.find({ adopted: false });

Concept: In more advanced scenarios, you might need to filter records by multiple conditions and sort them by a certain attribute. Sorting lets you arrange records in a meaningful order (e.g., by signup date), while filtering narrows the dataset.

English: Find all the monsters that aren’t adopted yet and show them to me, starting with the ones added the longest time ago.

SQL:

SELECT * FROM monsters
WHERE adopted = false
ORDER BY date_entered ASC;

doc:

db.monsters
.find({ adopted: false })
.sort({ date_entered: 1 });

Concept: A one-to-many relationship connects each monster to multiple incident reports. A monster can have many reports, but each report references only one monster.

English: Get all the reports written about Fluffy.

SQL: SELECT * FROM reports WHERE monster_id = 1;

Doc: db.reports.find({ monster_id: 1 });

Concept: Many-to-many relationships allow multiple entities on both sides to be associated with one another. In this case, a monster can have many favorite foods, and a food can be the favorite of many monsters.

English: List all of Fluffy’s favorite foods.

SQL:
SELECT foods.name FROM foods
JOIN monster_foods ON foods.id = monster_foods.food_id
WHERE monster_foods.monster_id = 1;

The join is basically a temporary table that is created with those two – which is then used to run the query. Note the automatic naming conventions.

Doc: db.monsters.find({ id: 1 }, { favorite_foods: 1 });

Concept: A many-to-many relationship is often used to represent friendships or associations between entities of the same type (e.g., monsters and other monsters). This is done using a junction table that references both monster IDs.

English: Find all the monsters who are friends with Fluffy.

Up until now, the table-based and document-based examples have been largely similar in how they retrieve data. Whether we were filtering, sorting, or finding single records, both approaches used fairly equivalent methods with comparable levels of complexity.

SQL:
SELECT * FROM friendships
JOIN monsters ON friendships.friend_id = monsters.id
WHERE friendships.monster_id = 1;

Doc:
db.friendships.find({ monster_id: 1 }, { friend_id: 1 });
db.monsters.find({ id: { $in: [ /* previous query */ ] } });

Relational databases allow for more complex queries like JOINs, while document-based databases typically require multiple queries for related data, offering more flexibility but potentially more complexity when retrieving related documents.

And you’ll need to allow users to add their friends.

English: Make Bruno friends with Grizzle using their IDs

SQL:
INSERT INTO friendships (monster_id, friend_id)
VALUES (4, 3); -- Bruno's ID is 4, Grizzle's ID is 3

Doc:
db.friendships.insertOne({ monster_id: 4, friend_id: 3 });