Jim Starkey wrote:

>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.
>
>

Jim,

I got the reasons, no problem here.

The point I was talking about is how to (if there is a way) change the
system tables names, create a system schema, and maintain backwards
compatibility with previous clients.

From what I read on this discussion, the majority of people like a
column for schema name and another for the table name on the relations
table. You argued about backward compatiblity, what I suggested is a way
that it could be achieved (at least I see this way).

The old clients will just see a "compound" table name trough the view
rdb$relations, new clients will use the real system tables on the
"System" schema.

Why views doesn't solve this point ?

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br