Let’s talk about frameworks, DBA edition
In the previous entry in this series I took a look at some common criticisms programmers level against the new generation of web-development frameworks. Today I’ll be following up in somewhat the same vein, by expounding on something that might lead your friendly local database administrator to look somewhat askance at how these frameworks do things.
And let me say right now, before I ruffle anyone’s feathers, that when I talk about applications and databases below, I won’t be talking about any particular application or database. I’m not engaging in thinly-veiled bashing of Java or Visual Basic, or of SQLite or MySQL, or of anyone or anything in particular. I’m just telling it like it is.
Life ain’t easy for the DBA
Let’s face it. When you’re a DBA you have one of the most important yet underappreciated jobs anywhere in the corporate world. Your company’s data is under assault from all sides, and you’re the only line of defense: bad data comes flying at you, redundant data gets shot your way every day and people look at you funny and say, “Integrity? What’s that?” You’ve lost track of the number of times you’ve tried to explain normalization to the people writing application code, and so now you just send out a link to William Kent’s introduction to normal forms every time it comes up.
Bottom line: the company has a dozen applications which all need to talk to one crucial database, and you’re the only thing standing between that life-giving data and the daily threat of disaster.
And then one day at lunch you overhear one of the application programmers talking about a new framework he found; he’s really excited and wants to use it for the company’s next big web-based project. You’ve learned from experience that you need to stay on top of what the programmers are doing, so you go to Google and look up this framework and start poking around in the code. And you recoil in horror when you realize that it does validation and integrity checking in the application layer.
There’s a cardinal rule in your profession, and it’s very simple: applications are not to be trusted. They may do validation and integrity checking, or they may not. Even if they do there are bound to be bugs. Left to themselves, these applications would store the same data in five different places and only remember to update it in three, then store it in five new places to “fix” the error. Which leads us to the inevitable conclusion: only the database can possibly be relied upon to know what the data should look like. Only the database can possibly be relied upon to maintain integrity. Only the database can be trusted.
And here this guy wants to use something that foolishly assumes it can safely do all its validation at the application layer? Truly, you have descended into Hell.
We feel your pain
But maybe you’re not alone down there. Consider the poor, beleaguered framework developer. He doesn’t just have to deal with writing suitably generic data modelling systems. He doesn’t just have to deal with writing an object-relational mapper. He doesn’t just have to deal with URL dispatching or templating or the arcana of server gateway protocols. He also has to deal with databases.
Some databases are angels. They implement nearly all of SQL and they have solid tools for validation and integrity checking. They make the framework developer’s life ever so much easier.
But some databases… aren’t angels. They have only the foggiest notion of constraints. The number of column types they implement can be counted on one hand. They think a “transaction” is something that happens at the bank. But framework developers have to support them nonetheless, because people like to use these databases for web applications and if we didn’t support them we’d lose our userbase.
Which leads us to the inevitable conclusion: the database can’t be trusted. Only the application can be relied upon to know what the data should look like. Only the application can be relied upon to maintain integrity. Only the application can be trusted.
Seriously. We feel your pain.
Why can’t we all just get along?
So a good framework has to have validation and integrity checking at the application layer. And a good DBA has to insist on validation and integrity checking at the database layer. But here’s the thing: these aren’t mutually exclusive approaches.
Even if every database supported the full range of validation features you’ve come to know and love, there would still be plenty of things that a web application would want to check itself first. Since the bottleneck in a web app is almost always the database, doing at least some of your validation up-front is going to help performance quite a bit — up-front validation means more errors are caught immediately, which means fewer hits to the DB in the long run.
Not to mention the fact that not every type of input validation you might want to do is cleanly supported in any database, angelic or not; it’s true that some databases have their own Turing-complete programming languages, yes, but for validation that’s not covered by straight SQL you’re probably better off jumping to the application layer.
And even if every application implemented flawless validation, you’d still want to have those constraints at the database layer, because you can never have too many safeguards for mission-critical data.
Of course, now you’re saying “What about DRY? You can’t have validation in both layers without repeating something somewhere!”
Except you can. The single point of reference is, and will always be, your database schema. Maybe that schema is written in the database’s DDL and the framework introspects to figure out what it needs to know. Maybe the schema is written in a programming language that gets translated by the ORM into the necessary tables and constraints. But wherever and however it’s defined, the schema is still the single authoritative source, and DRY is preserved.
And, more importantly, your data is safe. Application and database work in concert, the lion and the lamb lie down together and world peace ensues.
OK, maybe that’s a bit of an exaggeration. But the bit about applications and databases is true.
And that’s a wrap
Hopefully by now I’ve provided a little something for everybody, and we’re all on something resembling the same page when it comes to talking about the new web frameworks. Whether one of them is the right choice for your next project is still something that only you can decide, but I’d like to think you’re on a little firmer footing now for figuring that out: you know that if you’re going to be in the big belly a framework could be an attractive option, you know that frameworks can be a big boon for designers, you’ve seen some common programmer criticisms answered and we’ve got your DBA sitting around the campfire singing “Koom-ba-yah” with us.
So now it’s up to you. Take a look at Wikipedia’s list of frameworks to see what’s out there, start poking around in documentation, don’t be afraid to get your feet wet and feel free to ask questions when you have them; the people who develop these frameworks tend to be pretty friendly and helpful, and will be happy to help you find answers, even if the answer ends up being that a framework isn’t right for you.
Tomorrow: I return to irregularly-scheduled blogging.