Re: Specifying all biz rules in relational data

Fredrik Bertilsson wrote:

>> My own experience and inclination has always propelled me towards code
>> generators

I will take issue here and then proceed to the example. It seems we have very different views, so hopefully a discussion will be illuminating.

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

In other words, like diamonds, data is forever, while code is not. So I want to capture my most valuable asset, knowledge of biz rules, in data, not in code, so that I can re-implement that knowledge over and over as the whims of change blow through the industry.

If I may be so bold, I would restate your position as a quantity/quality argument. If there is a large enough *quantity* of desirable features in a language, then its very *quality* changes and it becomes a new type of beast. As a first response, I would say, "well, that's what they said about structured, that's what they said about object-oriented and so forth." But the best response is simply that data is far more valuable than code, so I actually want as much of it as possible, and once I have it, I then realize that so much code can be generated. My real asset is the data, and I can write generators for the language-of-the-month if there is a market for it.

> In my sourceforge project (http://butler.sourceforge.net), I have a
> code generator that generates java classes for tables in a database
> schema. If you have a column named "ConctactName", the generator will
> produce two methods:
> * public String getContactName()
> * public void setContactName(String name)
>
> But if you have a more powerful language, like Python, with dynamic
> properties, you can retrive the value for "ContactName" by typing:
> record.ContactName
> And generated classes is not needed.
>
> It is also very important not to generate more than absolutely
> necessary. In Butler a fragment of a generated class would look like
> this:
>
> public String getContactName()
> {
> return (String) get("ContactName");
> }
>
> As you see the generated code do nothing more than casting the return
> type and eliminates the usage of typing column names as strings.
>
> The real functionality is inside the get-method of the super class.

How do you answer the objection that, no matter how flexible the language, once business logic has been coded in that language, it becomes "trapped" in a format that can only be "mined" later at great expense, after the original programmers have left, the shop has been sold (twice) and the new customers have different objectives. Suddenly a hot-shot comes along, realizes his/her future depends on planting a new flag on a new mountain, and declares the old system "legacy" and begins work on the new one. Because the cost of reverse-engineering the system is so high, the asset has depreciated completely, its value becomes zero as it is discarded by the powers that be for their shiny new system (which will probably have half the features and run at half the speed).

This is my quantity/quality argument restated. Data and code are two very different kinds of things, and no matter the *quantity* of desirable features in a language, it will never be the *quality* of animal that makes it the most desirable form for the permanent store of biz rules.

>

>> I wonder what the participants in this newsgroup feel about that
>> proposition, that being that a database application can have its entire
>> behavior defined by scalar values that can themselves be organized into
>> relational tables.

Let me take issue with the statement that "...if your solution still makes it possible to have procedural..." It is precisely this idea that I challenge. If I can state precisely my chain of reasoning:

1. Given that the relational model is sufficient for all known business modelling situations,
2. And given that there are a finite number of structures that can be used within the model,
3. Then a DD/generator system can support this finite number of structures and...
4. This is sufficient to implement all known business information situations.

This leads to the direct conclusion that it is actually wrong to allow for programmers to slip in procedural code. While it may be necessary in the development of the system, to deliver goods while the system is being developed, the vendor will always be more profitable if the pattern of the exception is identified and put into the system.

Since the GUI is not business rules, then of course we would be happy to accept payment from anyone willing to pay to change the look of things, but then again the later stages of maturity for the system would be to support skins.

> But I also think that application development could be simplified
> using more high-level languages. Some years ago it was very popular
> with trying to storing business logic in XML-format. But the reality
> showed that this was only possible in some situations. (For example:
> Web applications can be defined in XML using tag labraries, but it is
> much harder to do with swing appl). But using a language like Python
> would make a very compact solution.
>
> /Fredrik

Well, we can probably both agree that XML is not as useful for as many things as many people think :) But here it seems the mistake is in choosing XML instead of in choosing data itself. If a complete model of meta-data is developed, then like all relational data it could be stored and transported in XML, comma-delimited files, or anything you desire.

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?

I will check out your site. I have yet to publish version 0.1 of my own, but am hard at work and looking forward to it.

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