Databases Roadmap: Store, Find, and Protect Information

A database is an organized memory for a product. A spreadsheet can be enough for a small manual workflow. A database becomes valuable when many users or programs must read and update information consistently.

The map

flowchart TD
  Need[What information must the product remember?] --> Shape{What shape and guarantees?}
  Shape -->|Related records and transactions| SQL[Relational / SQL]
  Shape -->|Flexible document-shaped records| Doc[Document / NoSQL]
  SQL --> Engines[PostgreSQL or MySQL]
  Doc --> Mongo[MongoDB]
  Engines --> Ops[Indexes, backup, security, monitoring]
  Mongo --> Ops

The five ideas to learn first

1. A record describes one thing, such as a learner.
2. A field stores one property, such as the learner's name.
3. A key identifies a record and can connect it to another record.
4. A query asks for or changes selected information.
5. An index makes selected lookups faster, at the cost of space and work during writes.

Relational databases and SQL

Relational databases organize data into tables with defined columns and relationships. SQL describes the result you want.

SELECT topics.title
FROM topics
LEFT JOIN completions
  ON completions.topic_id = topics.id
  AND completions.learner_id = 42
WHERE completions.topic_id IS NULL
ORDER BY topics.title;

PostgreSQL and MySQL are both capable general-purpose choices. PostgreSQL often appeals when a team wants rich SQL features and extensibility. MySQL is widely used and has a large operational ecosystem. For a beginner project, whichever is easiest to run and receive support for is usually the right first choice.

PL/SQL is Oracle's procedural extension to SQL. Learn it when you work with an Oracle system, not as a prerequisite for understanding databases.

Document databases

MongoDB stores document-shaped records resembling JSON. This can be convenient when related values are usually read together. Flexible shape does not mean “no design”: identifiers, validation, indexes, growth, and update patterns still need deliberate decisions.

Need	Good starting direction
Orders, payments, inventory	Relational database and transactions
Flexible content records	Consider a document database
Relationships and reporting	Relational database
Temporary cache or counters	A specialized store such as Redis

This is a starting heuristic, not a universal rule.

Design before choosing a product

Write down the questions the product must answer. For a learning tracker:

• Which topics exist?
• Which learner completed a topic?
• When was it completed?
• What happens if a topic is renamed or deleted?

Then sketch records and relationships. Use sample data and test the important queries before optimizing anything.

Operate the data safely

A working query is only the beginning. Production data needs access control, validated inputs, backups that have been restored in a test, monitoring, and a change process. Indexes should follow real query patterns. Replication and partitioning solve scale and availability problems, but add failure modes.

Practice path

1. Model three tables: learners, topics, and completions.
2. Insert two learners, three topics, and several completion records.
3. Query completed and unfinished topics.
4. Add a unique rule preventing duplicate completion.
5. Export a backup, delete the local database, and restore it.

The last step turns “we have backups” into evidence that recovery works.