Re: Specifying all biz rules in relational data

Fredrik Bertilsson wrote:

>> My own first principle is this:  Code is a non-portable depreciating
>> asset, while data is a portable appreciating asset.

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.

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.

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.

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?

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