"Robert B. Easter" wrote:
> A database is capable of more flexibility than a programming language
> with regard to how it can store objects. A database it not constrained
> by hardcoded runtime and compilation dependencies like objects in a
> programming language. Changing the data structure of a program means
> reprogramming then restarting the program.
Well, my favoured language is lisp which can actually change its
structures, even its code and polymorphic rules at runtime.
> If made right, a database can evolve its classes without ever going
> offline. I think there are some differences and so I don't
> see programming language precedents being so relevent.
Ok, programming languages aren't a precedent. Is there another database
as precedent? Give me something to work with here.
> I'm just proposing things to see if we don't over look some
> possibilities. Under my ideas here, UNDER can be implemented more like
> to spec (maybe exactly). INHERIT can pickup the Postgres extensions
> until a standard covers it too.
It sounds to me you're worried about the implementation rather than the
spec. IF someone were to bother implementing that layout it should
probably just be an option - not affecting semantics. CREATE TABLE
foo(...) UNDER bar LAYOUT IS HIERARCHIAL or LAYOUT IS SINGULAR. That
would complicate the code a lot though. Personally I think if it was
implemented the way the spec implies it would create an extra join for
every inheritance declaration. Avoiding that is the whole reason to have
an object database. If you don't care about another join for every
inheritance you may as well use a pure relational database with a mapper
library like persistance because you're not gaining a whole lot. On the
other hand with the current implementation (which is pretty much how
every ODBMS and ORBMS I've ever seen works), there is very little
downside. If you implement a single index that indexes subclasses then
both index scans and sequential scans will be pretty near optimal with
no joins. Compare against who knows how many joins if you split it up.
The only minor downside is you maybe lift a little more data off the
disk IF you happen to be doing a projection of super-class attributes.
But an ODMG interface would hardly ever do that anyway.
