Re: Just one more anecdote

Hugo Kornelis wrote:

> On Wed, 03 Aug 2005 23:26:41 -0400, Kenneth Downs wrote:
>
> (snip)

>>What I said was that you can take the user's needs and think about them
>>directly in terms of the end result - tables.  Using either white-board,
>>chalk-board, GUI design tool, or paper and pen (my own method), you state
>>the record-keeping needs in terms of tables that will hold the
>>information.
>>You erase, change, and modify until the needs are precisely stated.  At
>>this point you have completed analysis, and ain't that the dickens, you've
>>got table designs also.
>>
>>Stating the needs in any other way is incomplete unless you have enough
>>information to design the tables, so why not just state them as table
>>definitions in the first place.

Yes.

>
> ORM is an analysis method. But the completed ORM model holds *MORE*
> information than can be mapped into tables. An ORM diagram maps to
> tables, primary key, unique, check and foreign key constraints, plus a
> bunch of constraints that can't be directly implemented in any RDBMS
> that I know of.

If it is true that they cannot be implemented in the the DMBS then I reply:

1. not interested, as that creates a DB that cannot defend itself from a misbehaving client, and
2. overly complex constraints are usually the sign of tables that are too sparse.

Also, if it is true that there are elements beyond tables and primary and foreign keys, then I would suggest that systematic treatment of automation would finish the picture and allow the entire application to be specified in terms of tables.

And finally of course is the general rule that one should never design tables on object-oriented principles, anymore than one designs women's clothing on male models.

>
> I'd say that stating the needs as table definitions is incomplete.
>

In my experience when a programmer is doing the job it is the table definitions that are incomplete, usually because the programmer does not think in terms of tables and can't wait to start coding. Such programmers as these are usually convinced their design is so clever and unique that it requires their weird special techniques to implement. Usually they are wrong. More work on the table design would iron out a lot of the areas of apparent special need. I am not accusing you of any of this, mind you, as we don't know each other, but I have turned over the same rock and found the same spiders so many times I'm not interested in turning over that rock anymore.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)