Re: Specifying all biz rules in relational data

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Tue, 14 Sep 2004 11:39:34 -0400
Message-ID: <nb37ic.r09.ln_at_mercury.downsfam.net>


mAsterdam wrote:

> Fredrik Bertilsson wrote:
>

>>>My own first principle is this:  Code is a non-portable depreciating
>>>asset, while data is a portable appreciating asset.
>> 
>> It is possible to make code portable (between opertating systems).
>> 
>>>In other words, like diamonds, data is forever, while code is not.
>> 
>> I almost agree. In history data has changed from flat files to
>> hiarchical databases to relational databases. It is not for ever, but
>> almost. But of course programming languages changes much more often
>> than database paradigms.

>
> It seems to me that the OP looks at "data" as meaningful by
> definition. Looking at it that way, no data change occurred when
> moving the bits and bytes representing the data from "flat files to
> hiarchical databases to relational databases.", none at all.

Assuming the data is correct :)

>
> I have been involved in the developement of
> several largish applications, including a complete
> CRUD-GUI (+ some CRUD scripting system) mostly for
> testing purposes. Maybe 10% of the programming
> budget went into that. When you have the CRUD-stuff
> you aren't anywhere near a serious application -
> in my experience.

Please elaborate on the other 90%. My own experience is that after the table maintenance comes custom forms and labels (grunt stuff), bridges, which can be generated, and posting streams, such as posting AR cash. It does not quite come to 90%, perhaps 50%.

Of course, what also happens in the corporate world is that it is discovered after the fact that the salespeople and client-side project managers have been happily fooling each other and when the system hits the ground there are huge areas missing, incomplete, or downright wrong. Then the emergency calls come in and all hell breaks loose. In my experience this is where about 50% of serious coding gets done, but it is never documented and nobody understands it except the guy who stayed through the weekend to do it. Then there is the guy who stays next weekend to weed out the bugs from this weekend.

This is where being able to add or redefine columns and having the changes ripple through into the docs and all architectural layers looks good to me and has helped me most in the past.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me
Received on Tue Sep 14 2004 - 17:39:34 CEST

Original text of this message