|XP is just a number|
I like my database models to have some meat on themby danb (Friar)
|on Apr 27, 2010 at 15:22 UTC||Need Help??|
As long as the models are eating celery and diet pills, the database will be weak as a kitten, which means the system as a whole will be slow and weak. Put them on a heavy diet of procedures, triggers, views, rules, etc., and the system will have awesome power that only comes with fat model thundertheighs.
Features, flexibility, and performance are just some of the advantages. The most important is probably improved data integrity. Many apps rely solely on their own data scrubbing to prevent bad data from making it into the tables, but constraints in the database itself the vital inner citadel.
Another big one is reliability. When someone reinvents the wheel (e.g. transaction save points or cascaded deletes) in the application instead of using those features in the database, they are unlikely to put as much development effort as the database vendor did. That means they will be bitten by esoteric bugs and corner cases that only come out after long testing periods or over a wide number of production deployments. Using those heavily tested features of the database improves reliability and reduces bugs.
But the most important value of databasism to me, personally, is clarity. Moving thousands of lines of code out of the application and into the database where it belongs has a tremendous simplifying effect on the application source. It can make something that was impossibly complicated down to just managable. Moving data-related stuff to the database improves readability, simplicity, and clarity.
The other side has advantages too. Using powerful database features is like a towering redwood that put its roots down deep. It's very hard to just up and leave one database program for another. On the other hand, reinventing the wheel in your application is like weeds. They have no strong roots, so you can pull them up easily and spread them anywhere.
Another advantage of the skinny database model is the fun of reinventing the wheel. The design and implementation phase of building your own database features is super fun. Who doesn't enjoy building cursors, compound data expansion, transaction processing, or other database features that commonly get implemented at the app level? Of course, the bug fixing phase does not result in much enjoyment.
Using the existing and proven solution of the database itself is the boring and superior option.