Re: Specifying all biz rules in relational data

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Mon, 13 Sep 2004 10:46:25 -0400
Message-ID: <2sb4ic.jo.ln@mercury.downsfam.net>

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

While this statement is true, code is by its nature non-portable and it takes continuing effort to keep it portable. In contrast, data by its nature is easier to transform from format to format, so even the least mature products that deal with data tend to have healthy import/export facilities. A case where I argue a significant difference in degree does become a difference of kind.

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

But the data itself does not change, even as it goes from paper to magtape to disk, through EBCDIC to ASCII to Unicode. So if Joe Bleaugh died in the American Civil War in 1863, that fact remains even as the memory of that fact is keyed into a computer from a 140-year old index card.

This is what I mean when I say data is forever. This is behind the drive to attempt to capture biz rules in data, because they become a different kind of asset.

>

>> My real asset is
>> the data, and I can write generators for the language-of-the-month if
>> there is a market for it.

>
> This is true for some applications, but not for all. For example, I am
> working with an application that among other things calculates the
> salary for employees every month, according to complicated swedish
> rules and laws. In this case, the calculation algorithms is the read
> assets, not the data. And I see no possibility to auto-generate this
> algoriths.

Oops, I may not have been clear here. I agree that the implementation of many solutions requires procedural code, with the question of where that code goes being totally separate. The real question is, can the algorithm be expressed purely in data? My claim here is that it can, and moreover, that it is worthwhile to do so.

Is it worth discussing the particulars of the calculations, so that I can propose a format for describing the algorithm in data? I have done payroll myself, and my own experience is that it is an effort by lawmakers to see how complicated they can make a system that involves only addition, subtraction and multiplication. If you are able to share any of the details, I will provide my depiction of the solution in data.

>

>> 4.  This is sufficient to implement all known business information
>>     situations.

> I don't agree.

Amongst the four points, where was the broken link in the flow of logic?

>

>> On another track, you state above, "It is also very important not to
>> generate more than absolutely necessary."  Can you elaborate more on your
>> development philosophy with respect to the role of the stored data, the
>> generated code, and the hand-coded elements come together?

>
> If you have all your business rules in some sort of control tables,
> why do need to generate at all? Your application can read this control
> tables and create a GUI (or something else) runtime. Of course
> generated code will have better performance, but once you have
> generated the code, you need to re-generate if you change your
> generator. If you don't generate, changes in your application will
> have effect next time it is started.
>

Agreed that an application can read the control table at runtime, but agreed as well that the performance hit is completely unacceptable, hence the strategic decision to go for the generator instead of the interpreter.

On the other point, that you have to regenerate, to me this is a feature not a bug. Since you always plan to throw one away, much better to change some control entries and regenerate then to schedule time with the coders. In fact, doing one better, if all you have to do is push a button to regenerate, why not plan to throw away 3 or 4 and make it pristine before delivery?

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me

Received on Mon Sep 13 2004 - 09:46:25 CDT