Hi, Jim!

> The idea, in short, is venerable, elegant, powerful, and
> completely neglected. It should be compelling -- it's
> simultaneously more powerful than and completely compatible
> with the relational model -- but has generated next to no
> interest. Selling ideas to the database world is almost
> impossible. I think I originated the idea of a date as a
> formal data type, but it took SQL five or six years to
> recognize the utility.

Actually, PostgreSQL and Cache implement table inheritance. Oracle
people implements type inheritance and polymorphism, but very, very
ugly. As I said earlier, most databases take one or two OO features
without considering the whole picture and Object-Oriented Design
principles. Taking them they also tend to break relational model by
introducing objects as an outside concept.

> I'm not sold on the utility of methods on tables. The model
> that has worked well on databases are complex triggers fired
> by simple updates.
> The model works even better if the triggers themselves are
> table independent. Perhaps this is little more than a
> workaround for the absense of a type hierarchy, but it's not
> a feature I would surrender easily. The practical problems
> with table methods are they significantly more expensive than
> host language functions and don't integrate well into the
> host language(s). Encapsulation is a very compelling
> concept, but I'd need to be convinced that table specific
> methods solve a real problem.

There is no problem with table methods, especially if you have many
different programs accessing database.
You should be able to call them in SQL, just like you access table
fields.

When you have all object-oriented principles implemented in database
existing object-oriented design and implementation methodologies become
directly applicable for database schema. Classical object-relational
mapping techniques become redundant because they are implemented in
database internals.

Object-oriented design created using current approaches (UML, Booch
notation, etc) maps directly into database. This is good for
time-to-market timings and should simplify development. Business logic
becomes nicely encapsulated in database, but at the same time data is
accessible in relational form via SQL so reporting and other massive
operations are easy.

Without table methods mapping object methods to relational model is
extremely cumbersome.

> The model that has worked well on databases are complex triggers fired

by simple updates.

> The model works even better if the triggers themselves are table

independent.

> Perhaps this is little more than a workaround for the absense of a

type hierarchy, but it's not a feature I would surrender easily.

Note that nobody asks you to surrender any of the existing RM features.
:-)

> Newton said he could see so far because he was standing on
> shoulders of giants. Dijkstra said our problem is that we're
> standing on each other's toes. Go read Hammer and McLeod.

Yes, sure. I analyze a lot of scientific papers as I do my work and I
read about table inheritance and table nesting before. I know this ideas
are not new.
Actually, the root of approach is the idea to port all Booch OOD
principles to Codd's relational model. I read both authors and very
familiar with both models using them in practice a lot. I just wanted to
do clean port of one to another, nothing special.


Nickolay