Re: theory and practice: ying and yang

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:ombbn2-l65.ln1_at_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.

But is it not a fact that you also generate code in the client environment? For example, with some program develoment language. So in this situation you have some code as sprocs and some code as client apps, and there must necessarily be some coordinationation tasks between these two code environments and the DB schema environment, especially in change management, and new versions of the "package".

While I agree, version control is required if sprocs are used, you are talking
about version control for the program developed client code as well, which is two moving parts in addition to the schema.

My point is to remove the version control for the external client apps by having all code in the sprocs environment, thus removing one of the coordination tasks, and effectively reducing the number of moving parts.

> 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.

I am an old drummer, and like the rhythm. It makes a good deal of sense.

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/music