Re: theory and practice: ying and yang

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sun, 05 Jun 2005 09:33:38 -0400
Message-Id: <ombbn2-l65.ln1@pluto.downsfam.net>

mountain man wrote:

> "Paul" <paul_at_test.com> wrote in message
> news:42a24837$0$1704$ed2e19e4_at_ptn-nntp-reader04.plus.net...

>> mountain man wrote:
>>>>Having business logic in the form of stored procedures offers no
>>>>advantage (with respect to data integrity) over having the business
>>>>logic held externally, if both are managed by the same person.
>>>
>>> There is an advantage. In the traditional manner, with the logic
>>> held externally it is essentially being held in another software
>>> that is separate to the RDBMS software.
>>>
>>> Examine the redundancies caused by definitions (especially of
>>> data schemas, and changes thereto) that are effectively held in
>>> two separate softwares. Each redundancy costs money, every
>>> single time it is visited. More costly though, and quite unseen,
>>> are the behind the scenes coordination exercises that are required
>>> to effectively manage changes to these two separate software
>>> locations.
>>
>> but even if your business logic is held in stored procedures, you still
>> in effect have two separate areas to update when schemas change. If you
>> change the table designs, you also have to change the stored procedures
>> to reflect those changes. The fact that they are stored in the database
>> rather than externally is a minor point, is it not?

> 
> 
> No, it is a major time-and-cost-saving factor, because potentially all
> changes are accessible to the RDBMS, and in theory can be scripted.
> 
> And if they can be scripted, perhaps one day they can be automated
> and scheduled, rather than being performed by a DB specialist.
> 

I've done it (over my own protests I will add), and there are no savings. There are big savings to implementing schema changes via scripting based on some metadata or data dictionary, but not for code. When you put sprocs into the db to be worked on by more than one person, its back to source control, and you have to reinvent some wheels, to say the least.

The only real advantage to having the code in the DB is that the server now fully implements biz rules. This makes possible complete data integrity with automation as well, not just constraints. Hence Ken's constantly pounding of the code generation drum.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

Received on Sun Jun 05 2005 - 08:33:38 CDT