Sunday, December 24, 2006

Less database, more code

Less database, more code... Is it a really healthy solution to long run and lot-of-users services? I recently started to think about it more and more. Especially, after been influenced by that. It really sometimes feels better just to keep as least data in the database as possible, and then proceed with all the processing in the application layer. We can do virtually everything, and we can do everything as flexible as possible. It's code, anyway! You are right - and sometimes it's kind of a headache, but I am talking about long run, remember? You don't want to be stuck with one database, because this is the only one which supports these or that functions. You don't want to pay huge money for support, just to be able to ask to fix something, on what you already made yourself dependent. You don't want later (while failing to find some database function in exactly this database or version) to move some logic into application layer. Come on, that happens. It really does, especially with time lasting upgrades of the database versions, changes of everything you can think of... And of course, by stucking on some point you do get all the "beauty" of adding extra fields, normalization, re-building relationships in the database... That can drop down speed of you application big time!.. just because over the time you stunned with few hundred different tables, and relationships between them suck as much as possible. And you can't imagine how to fix that now. And you have to keep everything up and running. Well, you can be nice to yourself saying that your initial database design was good. Well it was. It was. Was. But it is not now. And that is ugly weird situation with legacy applications. Blaiming your DBA not to update your database structure every week, or blaiming yourself that you didn't want to do code and database updates that often will not help either. You wish then to have everything in code, which you can change, update, delete or extend. When you need it. And you want your database to be built not following all the perfect-kind-of-database-DBA-rules, but following your logic, and your understanding of what we should keep in the database just for storage, not processing. No huge joins, no huge internal sub-selects.
Frankly speaking, it's a really huge thing. And again, no silver bullet here. I do not see it yet. It all depends, and this is the hardest thing. Think twice when you do something. Sometimes, it is better to build less prettier database structure, but better and workable code, isnt' it?

No comments: