Re: Just one more anecdote

On Thu, 04 Aug 2005 17:08:02 -0400, Kenneth Downs wrote:

(snip)
>> 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

Hi Kenneth,

Note that I typed "can't be DIRECTLY implemented". With triggers and other vendor-specific extensions, anything is possible.

>2) overly complex constraints are usually the sign of tables that are too
>sparse.

I wasn't referig to overly complex constraints. Unless you think that equality constraints, exclusion constraints and disjunctive mandatory role constraints are overly complex.

These constraints can all be represented in SQL by a CHECK constraint, but only if the fact types the connect to will all be grouped into the same table. If they are spread out over different tables, you'll need CREATE ASSERTION (defined in SQL-99, if I recall correctly, and not avaialble in all major RDBMS's). For the equality constraint, you'll need deferred assertion checking as well.

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

I'm not sure if I interpret you correctly. If you propose to add some symbols, notes, or whatever to the tables you've drawn to show the constraints that are not available as standard constraints in SQL, then this would indeed allow the entire application to be specified in terms of tables (plus extra symbols and notes).

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

Despite it's name, I wouldn't qualify ORM as being object-oriented.

>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
(snip)

I know. One of my jobs has had me standing in front of a class of such programmers, trying to teach them to first create a complete data model in (a variant of) ORM, then map that to the corresponding datamodel in RM (but including the extra symbols and notes, to ensure no data from the previous step is lost) and only then start building.

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

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)