At 03:48 AM 8/1/01 -0400, you wrote:

>Jim, now that you can look back and review the results of your past design
>decisions, what do you think about active tables? Are they a good idea or
>not?
>

If what you mean is active system tables in lieu of native DDL
support, I tend to think they were a bad idea. The benefits I
expected from them have never materialized, unlike the problems.

When I designed the DSRI architecture in 1982-3, there were three
contending database languages: Quel from Ingres, Sequel from IBM,
and DEC's Datatrieve/Datalanguage derivatives, and there wasn't
a hint of a standard. The goal of the DSRI architecture was to
support all three languages equally, which is one of many reasons
I invented BLR, leaving high level DML language processing to an
upper layer. Clearly a single character oriented data definition
language was inconsistent with the goal.

A goal of the Interbase implementation was standards compliance,
and since Interbase data definition semantics couldn't be expressed
in standard SQL, we had an insurmountable second problem.

SQL, of course, won, and Quel and GDML have been all but forgotten.
But SQL has remained a standard in name only, compliance being a
marketing rather than a technical issue, so the problem of non-standard
extensions is a matter of great indifference.

Netfrastructure is natively SQL, uses SQL data definition internally,
and does not support active system tables. I stopped worrying about
rigid standard compliance, particularly with regard to extensions,
because nobody cares. I have also omitted some good and useful
features (global field definitions, for example) on the basis that
people who buy database systems are too dim to appreciate the
advantages.

The Rdb/VMS guys opted to use a BLR-like DDL language called MBLR
for data definition. They did a lousy job designing it, and it
didn't work very well. In retrospect, I think I should have helped
them fix their design and skipped active system tables altogether.

Jim Starkey