>
> 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.
>
But a person is-a employee (allow me to momentarily step aside from the rules
of english grammer, if you would), and a person is-a programmer. That's why I
didn't call my table "job" :) [1]
I don't like the way some OO programming languages handle objects, if they
mean to say you can't change an object's type without performing a logical
data copy to a new object. If you don't use some kind of extra layer of
abstraction in C, you will end up with that problem: you'd need to copy all
that RAM over to change from one struct to another. Most people would rather
take that RAM copying hit than all the hits for allowing "room to expand" (at
least in some applications). However, postgres needs to provide that "room to
expand" for each tuple anyway, so to go through the same copying seems bad
(especially since we're no longer just talking RAM).
Take as an example python... it's easy to emulate other objects: just assign
to the attribute, even if it's not there yet, it'll add the attribute. Same
with python, it's providing room to expand for it's objects already, so why
do all the copying? Now compare with Java, and see why you'd be annoyed. It
has the facilities to change the objects all around, but you can't do it.
Even if you disregard all implementation details, and assume that the database
is intelligent enough to not redundantly write data (and if you could name
one such database, I would like to know), you're still doing something that
doesn't logically make sense: you're deleting and inserting atomically, when
the more obvious logical path is to expand on the data you already carry
about an entity.
I like entities to be mutable, at least as far as makes sense to an
application. Try telling an employee that as part of a promotion, they're
going to be fired, lose their workstation, then be re-hired, and get a new
workstation; I bet he'd have an interesting expression on his face (hey, at
least postgres guarantees the "A" in ACID, or else bad things could happen to
that poor guy :)
Thanks for responding, and I agreed with everything else you said. As you
might have guessed, I don't much like "most object-oriented languages" if
that's what they're going to try to tell me I have to do. Python works
nicely, however :)
Regards,
Jeff Davis
[1] Come to think of it, the JOIN operator seems to, at least on a first
thought, represent the "has-a" relationship you describe. You could have the
tuples "manager" and "programmer" in the table "job" and join with a "people"
table. Don't ask about inheritance yet for this model, I'm still thinking
about that one (does "has-a" even have an analogue to inheriteance?). Send me
your thoughts about this, if you should have any.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
