Re: Specifying all biz rules in relational data

mAsterdam wrote:

> Kenneth Downs wrote:
>

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

Hmmm. I will grant without argument that games as a category are more than a database, but in same breath I'll argue that the typical business application has little in common with games, see below.

>
> Most interactions are more complicated than this game.
> The users do *not* think in terms of what is stored in
> the database - they might not even know that there is one.

As stated above, while this is true for games, it is not true for business applications. IMO a well designed biz app will actually bring the users as close to the data as possible. In other words, if a business application is "CRUD plus", where the "plus" is everything you have to do on top of CRUD, then the idea is to have as little "plus" as possible. Keep the users very close to the data.

Here are some examples. One is the simple action of posting cash in an A/R application. The basic actions of entering the data are easy, we will call that CRUD. But this is a CRUD-plus situation, because in addition to entering the cash into AR, we have to cascade some data into the General Ledger. In the context of the original post, this is an action that follows patterns. It is the same basic pattern as printing checks in AP or Payroll, or posting AR invoices in the first place. In all cases you are have a user inputing some data, and then you map that data into the GL. Looked at in that way, you begin to ask questions like, "How can I design all of these operations so that they are instances of the same basic thing?" Once I've done that, I've reduced the amount of code I'm writing, and with it the amount of bugs, and reduced more operations to simple data dictionary entries. When it comes time to explain to the user what is going on, you bring him to the HTML page that displays the mapping tables, and there is your documentation. Once the user realizes that all posting streams are doing the same thing, you have made a friend.

Second example. A legacy application has a horribly denormalized set of quantity columns in its sales and production tables. So you have qty1, qty2, and so forth. To make it worse, in some cases there are cost01, cost02, you get the idea. When coding EDI imports and exports, you have to constantly transpose columns to rows and vice-versa. Here again the transpose can be mappable in a data dictionary. By extension, any lengthy import/export that substantially changes the structure of data can be specified as a series of a small number of operations.

The third example I am going to put in another thread, because I have some questions about it. It is the Allocation problem that you see in ERP apps.

You could sum my whole position as something like this. Customers pay us to write database apps. Since 'All Business Rules Resolve to Database Specifications', we should spend as much time as possible making extremely explicit tables. Once we have done that, the amount of support code (the plus in CRUD-plus) tends to drop off dramatically. It also happens when we do this that we recognize we are only doing so many things with data, so if we can write general handlers for a finite number of operations, we can generate some very powerful apps.

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