Re: Specifying all biz rules in relational data
Date: Mon, 13 Sep 2004 19:05:06 +0200
Message-ID: <4145d347$0$10528$e4fe514c_at_news.xs4all.nl>
>>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.
>>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.
The salary calculating algorithm (which can be represented in code in many ways, even in one programming language) is very valuable, no doubt. It carries the current abstract form of agreements, which have been negotiated by many people for many years.
To implement it, one needs to assure that all data required by the calculation is available at calculation time. So it needs data (and datamanagement) to become of actual value, actually used. While necessary, it is not sufficient.
> ... a lot of business problems can only be
> solved using procedural coding. Not everything in life is easy.
Even if it is possible to state the algorithm in a declarative way (I see no reason why not), these formulations may not be the most practical ones. So, I agree, of sorts.
>>4. This is sufficient to implement all known business information >> situations.
>
> I don't agree.
>
>>Since the GUI is not business rules,
>
> Correct in most situations. Mostly a GUI (in a enterprise application)
> do CRUD operations on records, with additional data validation. But
> there are also examples there the GUI has a lot of business rules, for
> example the control screen for a paper mill etc.
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. Received on Mon Sep 13 2004 - 19:05:06 CEST