| Subject | Re: [Firebird-Architect] [Re-post] DDL, Scripts, DFW, and Commit |
|---|---|
| Author | unordained |
| Post date | 2004-05-08T07:52:49Z |
[Didn't notice this making it through, my apologies if it did. Besides, I'm not sure how useful
reminders of academic/theoretical principles are.]
As a squeaky fly on the wall ...
I think this same thought (as Arno's, that is) is likely what prompted E.F. Codd to not only
require that relational database systems present system catalogs as relations that could be
manipulated in exactly the same manner as everything else, but to also note that it would
be "really nice" (not an exact quote) if they could be updated as well (this in his 12, later 13,
rules.)
As views are not always updatable, even in theory, I imagine he was afraid to make it a
requirement -- system tables exposed into the database namespace might act as views, and not be
updatable for logical reasons. (Note: as I recall, Firebird does not allow you to update any multi-
table view, even if it could be theoretically updated.)
In any case, exposing the entire system catalog, and making it updatable, seems to be the most
flexible way of providing users with a mechanism to make metadata changes, whereas (instead!)
providing a language construct for every possible change seems ... prone to failure?
On occasion I've needed to, say, change the domain of several fields at once, across many tables
(all "%_id" fields) -- being able to use the relational facilities I'm accustomed to in order to do
this beats the heck out of issuing individually crafted statements. I fully expect constraints on
the system catalog to prevent me from mucking up the metadata tables too badly, just as the DDL
statements would. Less syntax, more semantics?
Then again, my wishing star has heard a lot from me about wanting DDL to be entirely
transactional ...
-Philip
---------- Original Message -----------
From: "Arno Brinkman" <firebird@...>
reminders of academic/theoretical principles are.]
As a squeaky fly on the wall ...
I think this same thought (as Arno's, that is) is likely what prompted E.F. Codd to not only
require that relational database systems present system catalogs as relations that could be
manipulated in exactly the same manner as everything else, but to also note that it would
be "really nice" (not an exact quote) if they could be updated as well (this in his 12, later 13,
rules.)
As views are not always updatable, even in theory, I imagine he was afraid to make it a
requirement -- system tables exposed into the database namespace might act as views, and not be
updatable for logical reasons. (Note: as I recall, Firebird does not allow you to update any multi-
table view, even if it could be theoretically updated.)
In any case, exposing the entire system catalog, and making it updatable, seems to be the most
flexible way of providing users with a mechanism to make metadata changes, whereas (instead!)
providing a language construct for every possible change seems ... prone to failure?
On occasion I've needed to, say, change the domain of several fields at once, across many tables
(all "%_id" fields) -- being able to use the relational facilities I'm accustomed to in order to do
this beats the heck out of issuing individually crafted statements. I fully expect constraints on
the system catalog to prevent me from mucking up the metadata tables too badly, just as the DDL
statements would. Less syntax, more semantics?
Then again, my wishing star has heard a lot from me about wanting DDL to be entirely
transactional ...
-Philip
---------- Original Message -----------
From: "Arno Brinkman" <firebird@...>
> If every possible action is put in a nice SQL DDL statement this should be------- End of Original Message -------
> good, but i think many thirth party programs use the system tables for
> actions that aren't possible at all with DDL. Changing a NOT NULL field to a
> NULLable field for example.
> I often set the default collation of a database which also isn't possible
> with a DDL command.
>
> Regards,
> Arno Brinkman
> ABVisie