Samofatov, Nickolay wrote:

>Here are the following ideas:
>
>1) table == object
>2) object inheritance. If table inherits from another table records of
>child should be visible in all ancestors
>3) tables may have constructor and methods declared. Methods are called
>with "record" ("this") reference and are all virtual.
>4) table may contain details (tables==objects by themselves)
>
>
>

The idea of system of tables as a type hierarchy has been around for a
long, long time. It was proposed in the early 1980's as the semantic
data model (Mike Hammer and Dennis McLeod, SIGMOD, 1978). The
classical example is a system with ships specialized into warships,
commercial ships, and yachts. Warships were specialized into aircraft
carrier, submarines, and surface ships, etc. I had intended to base the
DEC JRD (it spent some time known as JSD) on the semantic model, but
couldn't get buy-in (I compromised to get blobs into the architecture).

At Interbase I did a a layered implementation. I wrote an external tool
that took Interbase DDL extended to include specialization, then
generated a physical base table to hold all records in the type
hierarchy and views with update triggers for each table in the type
hierarchy. The base table had a type field maintained by the triggers
and used by the views to filter records. It worked like a charm. The
prospect's application (inspiration is often driven by a need to both
eat and feed one's employees) required a type hierarchy of network
events. They liked the idea sufficiently well that they internalized,
eliminating the driving need for the utility. It's probably somewhere
in the attic on a tape for a drive that no longer exists.

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.
Blobs took much longer. [Interesting case. Externally, DEC called them
segmented strings; nobody noticed. Interbase called them blobs, and
they went through the industry like forest fire.]

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.

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.