The Database Landscape

One honest warning before the course settles in: "database" is a wider word than the last two pages let on. It covers several genuinely different families of tools, the way "vehicle" covers bicycles and freight trains — all of them move things, and picking one before you know the cargo is how projects go wrong. This page draws the whole map once, so you always know where you are and never mistake the chapter for the whole world.

Here is the honest shape of it: one family — relational databases — sits at the center of this book and of most of the working world. The others, gathered loosely under the name NoSQL, each solve a specific problem the relational family handles less gracefully. They get their own honest tour in Chapter 10. Today you just need the map.

Relational: the Center of the Map

Relational databases keep data in tables — the films, screenings, customers, and bookings from the last page will each become one — with declared relationships between them: the pointing you just met, made precise. You talk to them in SQL. PostgreSQL, MySQL, and SQLite are all relational engines, and when someone says "the database" at work with no other context, this family is almost always what they mean.

This is the family the next eight chapters teach, and the reason is not tradition. Its core ideas — structure declared up front, rules the database itself enforces, changes that happen completely or not at all — are the vocabulary in which all database conversations are conducted, including the NoSQL ones. Even a pitch for a document database is an argument about what to trade away from the relational baseline. Learn the baseline first and every other family becomes legible.

The NoSQL Families, in One Sentence Each

Four families, four shapes of data they love. Document databases (MongoDB is the household name) store each record as a self-contained nested document — wonderful when records vary in shape. Key-value stores (Redis) do one thing at lightning speed: hand back a value when given its name — the engine behind the caches that make busy websites feel instant.

Search engines (Elasticsearch) make text genuinely findable — typo-tolerant, ranked by relevance — which ordinary databases only pretend to do. And graph databases (Neo4j) store connections as first-class things, for questions like "friends of friends of friends" where the relationships are the data. Chapter 10 gives each family a fair portrait, including what each one gives up — because every one of them gives up something.

Why Relational First Is Not Nostalgia

It would be easy to assume the order of this book is historical — relational is older, so it goes first. The real reason is practical. The relational family fits the widest range of jobs, keeps the most doors open, and fails the most gracefully when your plans change. The Marquee's booking data — structured, interconnected, and unforgiving of errors — is exactly the data it was built for, and most business data looks like the Marquee's.

So this book hands you a rule of thumb to carry, and you should hold it as a starting point rather than a law: relational by default; something else when a specific reason says so. Real reasons exist — Chapter 10 names them honestly, and Chapter 11 builds the full decision framework. What the rule protects you from is the other thing: choosing a database the way people choose sneakers, by what's fashionable this season.