Re: Specifying all biz rules in relational data

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Tue, 21 Sep 2004 22:33:31 -0400
Message-ID: <s9oqic.d5v.ln_at_mercury.downsfam.net>

mAsterdam wrote:

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

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

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

You are correct, I spoke to soon. By Spight's law, any sophisticated program is managing data.

> 

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

Would agree completely, but say that the word "secondary" has to come out, or it becomes a loophole. Instead of thinking of processes such as "posting to the GL", we think of data definitions. We define a table that contains all transactions against an invoice (cash, credits, allowances). In another room somebody defines the GL as containing the summary of all financial transactions. Both definitions are primary. In linking AR to GL we are fulfilling primary definitions. Our implementation may be secondary in terms of architecture, but it is fulfilling primary definitions. The cash table cannot complete a transaction without posting to the GL.

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

Received on Wed Sep 22 2004 - 04:33:31 CEST