At 03:47 AM 2/9/01 -0400, Claudio Valderrama C. wrote:

>>
>> The origins of Firebird go back to DSRI (DEC Standard Relational
>> Interface) which specified a core set of system tables that
>> described everything, including themselves. Rdb/VMS, Rdb/ELN,
>> Interbase, a modest collection of gateways, and a database
>> replicator where built to the standard with a very high
>> degree of interoperability.
>
> Were all known system tables (with the exception of rdb$user_privileges,
>rdb$roles and rdb$formats) defined in the DSRI documents? Or with "core" you
>mean a few system tables?
>

Just the core -- RDB$RELATIONS, RDB$FIELDS, RDB$RELATION_FIELDS,
RDB$INDEXES, etc. And for each table, only the core fields
were architecturally controlled. Any implementation was
allowed to add more.

>
> Just curious, how did the other pre-relational engines deal with data
>definition?
>

IDMS-11 and its PDP-11 port (DBMS-11, aka elephant on a bicycle)
had a dictionary part of the database. VAX DBMS, also a CODASYL
database, used the Common Data Dictionary (CDD). The CDD was
a hierarchical entity/attribute repository, and was probably
the model for the Windows registry.

>
> It's near to impossible. Every engine has its own set of capabilities.
>Define an standard and it will be violated by every db vendor. The best that
>could be asked is a minimal set of system tables... now talk about the
>fields in those tables and we have 15 years of discussions. Some engines do
>almost everything through manipulation of real or fake system tables. (Take
>a peek at MsSql tables, for example.) However, much of those manipulation
>occurs with proprietary commands that extend (or mangle) SQL's DDL.
>

A core set of common system tables would be a very good thing, and
could be implemented on existing systems with views. New systems
coming on the market (like Netfrastructure) would be likely to
use them natively. New versions of existing products could migrate
to native usage, leaving legacy tables implemented as views. However,
the purpose of the SQL standard in the database industry is a barrier
to entry, not promotion of interoperability.

The JDBC standard is an honest attempt at interoperability and has
been quite successful. Do note, however, that it wasn't done by
a database company or with the official SQL committee, which was
busy inventing a stupid, overweight API that nobody will ever
implement or write to.

My opinion, strong held (surprise!), is that JDBC is good enough,
bless it, ignore the past, and move on to the future.

> A couple of times I've asked myself is DYN is necessary in those days. I
>know you created it initially due to a licensing restriction (gdef not given
>to customers) and not due to a technical problem, so maybe in the future
>things can be reshaped? The current behavior hurts my dreams, since it
>should be something like:
>- Send DDL through DSQL
>- DDL is recognized and DYN is generated
>- DYN is passed to the Y-valve
>- BLR is generated to change system tables
>- Db objects are created, modified or deleted.
>

When the DSRI architecture was created, SQL was only one contender
among many languages. QUEL (Codd's Alpha) was used by the academics,
Datalanguage (ARPA Datacomputer access language) derivatives were
used by DEC, Progress, and a few other 4GL vendors, etc. DSRI was
designed for language independence. We designed it to support SQL,
though SQL wasn't actually supported by DEC for another 3 or 4 years
(well after Interbase's SQL).

But those days are gone. SQL is universally regarded as "good enough";
a competing language is almost unthinkable. So moving SQL from
"outside the engine" to native makes sense. What might take sense
is to implement a second SQL based engine sharing the basic eval
mechanisms with the current BLR engine. Unfortunately (maybe
fortunately?) there is nothing of the current DSQL component that
could be salvaged, so the amount of implementation is significant.

>
>> I have made my peace with database standards by adopting
>> the JDBC interface as the native interface for the
>> Netfrastructure content store. In the long run, I
>> think Firebird would be well adviced to do likewise.
>
> Sorry for being a pain, but are you suggesting a change of known system
>tables or an addition of a new layer?
>

First as a layer. In fact, it already exists, just not as open
source. Later, as Firebird became more JDBC compliance, the
layer could be thinner.



Jim Starkey