On Thu, 5 Sep 2002, Jeff Davis wrote:
> You have 2 tables: Programmer and employee. Programmer inherits employee. You
> put in a generic employee record for someone, but then she becomes a
> programmer. What do you do? (I borrowed this example from a book by C.J.
> Date, who posed this question). Do you DELETE then INSERT? Something seems
> wrong with that somehow.
This is not so wrong. If you think about it, you have the same
problem in most object-oriented programming languages: a person
object can't generally easily become a subclass of itself after
being created.
This is a case, I would say, where you simply don't want to use
inheritance. A person has-a job, not is-a job.
> What about the database users, and their expectations of the behavior?
Nobody really knows; table inheritance in databases is not well-defined.
(Though perhaps the latest SQL spec. changes that.)
> However, I will stick to the well-defined relational model until I see
> something useful from the inheritance system that is as well-defined.
Amen! :-)
> Or, I suppose, if someone shows me something that I can't do in the
> relational model, but can with inheritance, I might be convinced
> otherwise.
I think that most people are at this point agreed that table
inheritance, at least as currently implemented in any known system,
doesn't offer anything that can't easily be done relationally.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC
