Relational Databases: What are They Good For?

I'll answer the question: they're typically good for a whole lot, provided a whole lot looks something like:

• Extreme concurrency support (if handled right)
• Solid transaction support, with well-known deterministic tradeoffs agains concurrency
• Deterministic (in both time and output), standardized (mostly) and accessible query capability
• Proven logging, failover, and recovery mechanisms
• Standardized management and operations tools
• Exposure of data to standard, existing reporting and OLAP tools
• Declarative management
• Declarative data cleanliness constraints
• And a few other things
  

Now, nowhere in that list does it say "great data structure for every problem domain" -- or even "great data structure for many problem domains." In fact, the relational model is inherently a good structure for a few domains, but by no means a large number.

And yet somewhere along the way, in the last 20 years or so, it's become a not-entirely-embarrassing-and-career-limiting-move to design a software system by initially modelling entities in a relational model, then slapping a wrapper above the SQL (maybe even auto-generated), tossing a UI on there, and declaring "Mission Accomplished." Wait! Where's the "business layer"? Well, that's where things start to go off track. Actually it's usually above the DB wrapper piece and below the UI -- but more importantly it's usually almost empty in the beginning, since the designer has an entity model that is tightly coupled to the current flavor of business rules. The business layer becomes a real monster ... er I mean tier ... later, when each case or change that isn't supported by the data schema earns a hack-around in the business layer. And at the end of the day all of these systems end up looking and acting the same way: like the 3-tier DB apps they are.

What's wrong with that? The fact that the apps end up expressing this architecture more strongly than they express solutions to their problem domain. These apps feel like fields and records -- they don't feel like what they actually are (e.g. a cell phone provisioning app, a flight management app, etc.) So they're mediocre and they're disliked by their users, disliked by their maintainers... they're "good enough" ... "until we have a chance to do it right."

For most apps, a database is a particular way to persist data, with some handy aspects, that's all. Don't design like it's anything else! Design like you're building a video game, like the experience is everything and only the user interaction needs to be right (and 100% right). The reality of business apps may be dirtier in the details (not to mention you'll rarely have the resources to make your UX dreams come true), but that's the point: if you're smart you can keep it in the details. Which means designing a whole application not just a database.