> Hannu Krosing wrote:
> >
> >but as E can be an INT in one subclass and TIMESTAMP or VARBINARY in
> >other
>
> I don't think that should be allowed. It violates inheritance principles,
> since the types are not compatible.
I see ... here's a person who has always programmed with typed
languages and now thinks, that this is the right definition .... it's
much more out there in the world. Open your mind and think about the
following:
An attribute named "a" of "type" TIMESTAMP of an instance of a class
can be seen as a relation from this class to the class TIMESTAMP and
this relation is named "a".
And if you're on the way to relations you're not far away to see,
that a relation is of course not limited to show to one specific class
... but perhaps to all subclasses also ... and this is not a
violation.
I know, that for many people these are only theoretical questions and
they may even be true with that, but "violation of inheritance
principles" is simply wrong.
But I also know, that we deal with a relational database and I do not
expect, that it will be as good as a pure object-oriented database -
but all those great wrapper software in the market work with
relational databases and they work pretty well - but I also see, that
they only use the basic technology to do their work.
The reason seems to be, that all those nice oo-features within all
those databases do not scale very well ... and they're good for a
single implementation. There're other problems out there:
- caching at the client side
- more powerful db desing evolution features. Change the type, the length of a typed attribute
Marten