Re: Storing query language in relations

"Tibor Karaszi" <tibor_not_pressed_ham_.karaszi_at_cornerstone.se> wrote in message news:<hv1n9.441$MV.20239_at_newsc.telia.net>...
> "Mikito Harakiri" <mikharakiri_at_yahoo.com> wrote in message
> > Why DEFINTION_SCHEMA tables are necessary in the vendor's
> > implementation? A vendor just need to implement INFORMATION_SCHEMA
> > views upon their (proprietory) catalog. Then, a user just updates
> > INFORMATION_SCHEMA views, which then triggers updates in the
> > underlying catalog.
>
> Yes, that is possible. But still I fail to see what is to gain. I doubt that
> updating the INFORMATION_SCHEMA view structure would be considered easier
> than DDL. Especially for the less experienced. But, that might be because
> one is used to read DDL instead of INS/UPD/DEL against the catalog...

The advantage would be that DDL isn't stored relationally in a normalised form.

You could I suppose regard SQL DDL as a view of the DEFINITION_SCHEMA tables just as the INFORMATION_SCHEMA views are. In fact I think most current DBMSs don't actually store the DDL, but generate it from the system tables on request.

So perhaps the point is more of a conceptual one - that we should move away from thinking of a query language as the primary means of interacting with the database, and the system tables as only an "underlying" storage for DDL. Instead the system tables become the main way of storing your DDL & DML, and SQL or other query languages are relegated to a mere view of these. Though as someone pointed out views and tables should be equivalent. I'm not sure how this would work here though because the views containing the SQL strings would have non-atomic values whereas the underlying tables wouldn't. So the tables would be in some sense superior to the views. And a "external" query language like SQL becomes an optional add-on to a DBMS instead of an essential part.

Paul. Received on Fri Oct 04 2002 - 12:20:45 CEST