Erann Gat <gNOSPAMat@jpl.nasa.gov> wrote:
+---------------
| "Karsten Poeck" <karsten.poeck.nadadespam@wanadoo.es> wrote:
| > A third solution uses two tables person and company (assuming that partner
| > is abstract)
| > but this has the disadvatage that all columns of partner have to be
| > duplicated in the tables person and company
| 
| Why is that a disadvantage?
+---------------

Think about the implications of a superclass with slots with class
allocation. If you duplicate those slots in multiple subclass tables,
you immediately run up against a consistency-constraint problem.

It seems to me that if you're look at the data with an "Entity/Relationship"
viewpoint (E-R modelling), than the the entities work o.k. as objects,
but only for a completely flat class hierarchy. The M:N relationships
don't at all (and 1:N and N:1 relationships are just subsets of those).

Try this concrete example: What would your object hierarchy have to
look like so that when a company changed the location of one of its
offices ("Branch #N"), all of the work addresses for employees who
work at that branch automatically change to match the new location?
Classically, in a 3NF database that information is *not* stored in
the employee record, but in a separate "company/branch#/address" table.
(Sound like a superclass with class-allocated slots?)


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607