Erann Gat <gNOSPAMat@jpl.nasa.gov> wrote:
| "Karsten Poeck" <email@example.com> 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 Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607