Evaluating Relational Databases

After a lot of research and a fair amount of sweat, you've reached the end of the design and implementation stages of the database life cycle. Your database looks good on paper, you've implemented it in SQL, you've steered around the common design mistakes covered in this module, and you've accounted for international business data. One nagging question remains:

Is the database correct?

That question splits into two genuinely different halves — the technical and the practical — and the answer to both halves turns out to be the same. Your database might sit comfortably in Third Normal Form and be perfectly ready to store data in any language from Swahili to Klingon, but if the people relying on it can't actually get answers to their real questions out of it, the database is useless. Technical correctness and practical usefulness aren't the same thing, and a database can score well on the first while completely failing the second.

It's worth being precise about what "wrong" actually means here, because the technology choice itself almost never is the problem. A relational database like PostgreSQL, a document store like MongoDB, a graph database like Neo4j, or even a plain flat file — none of these is inherently wrong. Each one was engineered to solve a specific kind of storage and retrieval problem well. The question was never "which technology is correct," it was always "which technology fits this specific problem."
That's exactly where things actually go wrong: not in the technology, but in the fit. Force a rigid, highly normalized relational schema onto unstructured, rapidly mutating IoT sensor data, and you can technically make it work — the data gets stored — while producing something painfully inefficient to scale or query. The database isn't malfunctioning. It's doing exactly what it was designed to do, applied to a problem it was never designed for. That mismatch, not any inherent flaw in the technology, is what makes a database useless.

Throughout the design process, you should be constantly checking whether the database you're building actually meets your customers' real information needs — not just whether it's technically sound.

1. Every table should represent a real business object, one that can combine with other tables to produce genuinely useful information.
2. Every constraint should actively help users enter correct data, not just exist for its own sake.
3. Referential integrity should be enforced wherever it matters, to keep table data consistent as the database grows and changes.
4. Views should combine table data into actionable information — the kind users can actually base real business decisions on.

Even a design that checks every box above can still fail in a way that has nothing to do with schema quality. A beautifully architected database is useless if the data sitting inside it is inaccurate, duplicated, or stale. In that situation the database itself is functioning exactly as designed — every constraint enforcing correctly, every relationship intact — while still failing to provide the business with a single reliable insight, because the inputs were never trustworthy to begin with. No amount of schema-level correctness compensates for bad data going in.

There's a third way a technically sound database can still be useless, and it's purely about performance: poor indexing. A database where critical queries take minutes instead of milliseconds, because the right indexes were never built, has its practical utility gutted regardless of how correct its schema is. A database that can't be queried efficiently by the application depending on it is effectively useless to that application — the platform it runs on doesn't matter if nobody can get an answer out of it in a usable amount of time.

A database that runs a bit slowly but reliably answers the questions that actually need answering is infinitely more useful than a lightning-fast database that contains no actionable information at all. That's the whole idea behind the statement this lesson is built around: "There are no wrong databases, just useless ones." Speed matters — the indexing point above makes that clear — but speed in service of nothing is still nothing.

Many developers focus so heavily on performance that they needlessly complicate things. They take a simple solution and make it harder to build and maintain, all in the name of speed. They denormalize tables to avoid using "too many" tables, and they build business rules directly into the database so they don't have to implement them separately through stored procedures or application code.

Modern hardware and software, though, is genuinely fast. These CPU-pinching measures often save only milliseconds on a query that already takes a full second. Think hard about whether a convoluted design will really save meaningful time before you make something so complicated that you can no longer build, debug, or maintain it. If you're not sure, either test it and find out, or go with the simpler version and revisit it later if it's genuinely necessary. Performance is usually acceptable by default; contradictory data is not.

I once worked on a huge database application where a simple data change might require five or more minutes of recalculation. After about three days digging through horribly convoluted code and database structure, I found the problem. The original developers had used a bunch of tricks to perform calculations in sneaky ways, saving a little bit of time here and there. Then they'd done something genuinely silly that caused the same calculations to run again and again, more than a hundred thousand times. They were so busy worrying about tripping over blades of grass that they wandered blindly into a patch of poison ivy. I managed to speed things up a little, but a lot of their time-saving tricks were buried so deeply in the underlying design that there wasn't much we could do without a total rewrite.

The moral isn't to ignore obvious opportunities to improve performance. It's to avoid getting so focused on the little things that they cloud the grander design. First, make it work. Then make it work fast.

Everything above assumes the database has actually been tested against realistic conditions — and that assumption fails more often than it should. Some developers perform little or no testing before releasing a database into the wild. They run through a handful of checks for basic correctness — the better ones work through every use case they can think of — and simply assume it'll hold up once real users get to it. Then customers try to use it under realistic conditions, and the whole thing falls apart: bugs the testers never found, performance nobody anticipated.

Test the database and any applications attached to it thoroughly. Fully exercising every nook and cranny of a system takes real work — every piece of code, every table, every constraint — but it's necessary, not optional. Load testing matters just as much: you need to know whether the database can actually handle the load it's going to see in production, not just the load it saw in development. If you don't find the bugs and bottlenecks yourself, your users will find them for you, guaranteed.

It's also worth being realistic: almost every non-trivial application contains at least some bugs, no matter how thoroughly you test it. That's not a reason to skip testing — it's a reason to be honest about the actual goal. You're not trying to catch every bug; you're trying to catch enough of them, and specifically the ones most likely to actually occur, that the probability of a user hitting one drops to something genuinely small. The bugs that remain will still be hiding in there. But if you're only fielding one or two user complaints a year, you're doing pretty well.

Taken together, this is what "evaluating a relational database" actually means: checking that the technology fits the problem, that the design serves real information needs, that the data itself is trustworthy, that it can be queried efficiently, and that it's been tested against conditions that actually resemble production. A database can pass every one of these checks and still not be perfect — but a database that fails enough of them stops being useful long before anyone gets around to calling it wrong.

The next lesson wraps up this module.