Subject: Re: CLOS and databases
From: (Rob Warnock)
Date: Sat, 20 Mar 2004 14:45:48 -0600
Newsgroups: comp.lang.lisp
Message-ID: <>
Erann Gat <> wrote:
| "Karsten Poeck" <> 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			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607