Re: Specifying all biz rules in relational data

Kenneth Downs wrote:
> 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%.
>>
>>Tough question, this. My first thinking was:
>>"the application!", but that does not look
>>very nice as an answer.
>>
>>Maybe this helps: Think of a multi-player game.
>>Just two players will do: Chess, tic-tac-toe, or the
>>(computer-)ancient, simple game of 'pong'.
>>Now think of two people playing it over some net,
>>others watching. Imagine the database,
>>imagine the cruds, imagine the userinterface,
>>the protocols, etc...

The only thing that really matters is the set of interactions, supported by the application. The games are an example.

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

It strikes me as odd, that interactions in games would generally be more complex than interactions in your typical business.

Surely there is a place for database-centric applications. With this type of application, the user is aware of most tables, and actively, conciously maintains data. Before automation you would see a bunch of people operating some filingcabinets with many relatively simple cards with mostly tabular data.

"CRUD plus" nicely characterises the automated version of this type of work, and I do agree here it is good practise to try keeping the "plus" as small as feasible, in order to preserve simplicity, and maintain the necessary table-awareness of the users.

The people with the filingcabinets, however, would typically not be the people doing the real business, but clerks: bookkeepers, administrators; they would provide a service to - games are also nice as a metaphore - the players.

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

Ah! The second level of automation. Yes, a lot of development results in (developer-shared) tabular data, and the developers may very well be served by administrators maintaining these. I would try to hide those tables from the original clerks, though. Nah - because of automation most of them are now jobless, so let's retrain (a few of) them.
Temporarily. Automate it and you have Meta-CRUD plus, the basic version for CRUD-plus apps being your everyday datadictionary. So ... let's keep the plus minimal, ok?

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

This would be the Meta-CRUD plus, right?

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

Nice thread! :-)

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

I would not formulate this as a position but as a type of automation. Specifically: this typifies automation of secondary (as in *not* the business core) processes. Received on Fri Sep 17 2004 - 09:35:11 CEST