Re: Sub-Entities

From: Jon Heggland <heggland_at_idi.ntnu.no>
Date: Sat, 2 Jul 2005 11:49:44 +0200
Message-ID: <MPG.1d308193befbf4139896c9_at_news.ntnu.no>


In article <1120273062.271114.45080_at_g49g2000cwa.googlegroups.com>, wbarthol_at_gmail.com says...
> When creating sub-entities should you put a column in the root table
> saying what kind of sub-entity it is, or is the presence of a row in
> the more specific table? For example:

Putting a column in the root table is redundant, since the same information is implied by the presence of the corresponding row in the more specific table---at least if it is the case that each ClientIdentifier in Clients is always present in either Individuals or Organizations as well.

You could put a column there anyway, to speed up some queries, but you would need quite a few constraints to ensure consistency in that case--- which will slow down updates.

> What is the best way to force a client to only be an individual OR an
> organization? Trigger?

Non-procedural constraints are in general better. One that says that the join of Individuals and Organizations must always be empty will do the trick. It gets worse if you have more than two sub-entities, though. And that constraint will not prohibit clients from being neither individuals nor organizations.

-- 
Jon
Received on Sat Jul 02 2005 - 11:49:44 CEST

Original text of this message