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.

--Daniel

In reply to I like my database models to have some meat on them by danb
in thread How aggressive is your database leverage in application development? by metaperl

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.