| Subject | Re: [Firebird-Architect] Multi-level name space |
|---|---|
| Author | Jim Starkey |
| Post date | 2006-01-13T01:40:49Z |
Ann suggested that it might not be immediately intuitively obvious on
why a multi-level name space is so important. I am reminded of fine
story about a lecture by an eminent mathematician. Part way through the
lecture he said, "Now it clearly follows that...". A student raised
his hand and asked, "Are you sure that that follows clearly?" The
mathematician paced back and forth for 5 minutes, looked out the window,
looked at the ceiling, looked at his feet, scribbled on the blackboard,
erased it, and scribbled again. Suddenly his face lit up. "Yes!" he
exclaimed. "It is clear!".
OK. The reasons for a multilevel namespace:
1. To avoid collisions between user tables and system tables. System
tables in Firebird are prefaced with RDB$ for runtime
compatibility with DEC's long forgotten database systems (one of
which is still owned by Oracle). RDB$ is not only ugly, but folk,
we ain't RDB -- that's somebody else. Dmitry want to introduce a
new prefix -- MON$ -- which is just as ugly but at least isn't
somebody else's product name.
2. To avoid accidental collision between table names from different
applications. Back in the old days when we had to walk four miles
to school in the drifting snow uphill in both directions, people
used to share computers and databases. If you install a second
application in single database, the probability that each will
have a table called "PEOPLE" or "EMPLOYEES" or "LOG" is pretty high.
3. To support multiple application instances. Contemporary
applications (mom now drives the kids to school in her SUV) are
web applications, and a single web server may dozen of instances
of the same application. Unlike the bad old days of accidental
table name space overlap, we now have 100% overlay since every
application has exactly the same table names.
We can't do anything about our classical system tables. They are
unqualified and must remain so. But new system tables can have spiffy
names like SYSTEM.REPOSITORIES and MONITOR.ATTACHMENTS. And if we can
slide this stuff in without breaking anything while simultaneously
reducing the code size and complex it enabling future extensibility
(just in case we didn't get it exactly right the first time -- it
happens, you know), well, cool.
why a multi-level name space is so important. I am reminded of fine
story about a lecture by an eminent mathematician. Part way through the
lecture he said, "Now it clearly follows that...". A student raised
his hand and asked, "Are you sure that that follows clearly?" The
mathematician paced back and forth for 5 minutes, looked out the window,
looked at the ceiling, looked at his feet, scribbled on the blackboard,
erased it, and scribbled again. Suddenly his face lit up. "Yes!" he
exclaimed. "It is clear!".
OK. The reasons for a multilevel namespace:
1. To avoid collisions between user tables and system tables. System
tables in Firebird are prefaced with RDB$ for runtime
compatibility with DEC's long forgotten database systems (one of
which is still owned by Oracle). RDB$ is not only ugly, but folk,
we ain't RDB -- that's somebody else. Dmitry want to introduce a
new prefix -- MON$ -- which is just as ugly but at least isn't
somebody else's product name.
2. To avoid accidental collision between table names from different
applications. Back in the old days when we had to walk four miles
to school in the drifting snow uphill in both directions, people
used to share computers and databases. If you install a second
application in single database, the probability that each will
have a table called "PEOPLE" or "EMPLOYEES" or "LOG" is pretty high.
3. To support multiple application instances. Contemporary
applications (mom now drives the kids to school in her SUV) are
web applications, and a single web server may dozen of instances
of the same application. Unlike the bad old days of accidental
table name space overlap, we now have 100% overlay since every
application has exactly the same table names.
We can't do anything about our classical system tables. They are
unqualified and must remain so. But new system tables can have spiffy
names like SYSTEM.REPOSITORIES and MONITOR.ATTACHMENTS. And if we can
slide this stuff in without breaking anything while simultaneously
reducing the code size and complex it enabling future extensibility
(just in case we didn't get it exactly right the first time -- it
happens, you know), well, cool.
>[Non-text portions of this message have been removed]
>