Re: theory and practice: ying and yang

mountain man wrote:

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

The coordination is handled by automation. What the two layers have in common is that both are governed by the data dictionary.

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

You can't get rid of version control, we have it as well for our two main bodies of code: the builder (or generator), and the client libraries. There are two programmers working on it, and since 2 > 1 that means version control :)

But it is much easier. When the body of code is kept small and very orthogonal, and heavily data-driven, much of the code versioning problem evaporates as you always just get the latest code. The problem does not entirely evaporate, though, it is moved over to spec maintenance, but that is much easier because it is data management.

>
>
>

>> 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_at_(Sec)ure(Dat)a(.com)