Re: organizing tables?

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:beu2h9$26v6$1_at_gazette.almaden.ibm.com...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:OJpQa.56107$H17.18016_at_sccrnsc02...
> > Hi all,
> >
> > I've been thinking about the need for an organization principle for
> > relational data. Imagine a dbms that supports many users and many
> > applications. After a point, the idea that one has a flat namespace
> > for databases within the dbms doesn't seem so nice anymore.
>
> I agree wholeheartedly that there very probably is (or at least would be
in a
> future RDBMS) a need for non-flat namespaces.

How do you get from wanting no names to wanting hierarchies of names? <g>

If one has a database name, an application name and a user name to determine the logical view of the database, how does one arrange them hierarchically? Why that choice?

> > What
> > if there are hundreds of databases? What if you want to be able
> > to import some of the tables from one database and some from
> > another, etc., into your person database?
>
> Logically it is much better to have just one database.

What's wrong with taking a projection of two database variables and combining the resulting values using union or join to assign to a third database variable?

> Different users can be
> given different views of this one database, so they might *think* that
there
> is more than one database (assuming two database views are completely
> isolated), but in the full picture there is just one logical database
> supported in any single (or distributed) DBMS. A hierarchical (or other)
> non-flat namespace could facilitate such a system.

What is so flat about current namespaces? Do you see any strong argument for arranging namespace components in hierarchies? Does the user name define a subset of the database or does the database name define a subset of the user's view?

> > It seems like you need to have some organizing principle. I hate
> > to say it, but the popular choice always seems to be a hierarchical
> > namespace.
> >
> > Anyone have any thoughts or are there any interesting prototypes
> > out there? It seems like this idea was the 05/25/2003: Quote of the
> > Week on dbdebunk.com. (Which is to say, I think they were
> > making fun of the idea.)
>
> I'm not aware of any particular work in this area that specifically
concerns
> databases. For me the difficulty would be how much you can make this a
model
> issue. I.e. are there any logical concerns here or is any design little
more
> that a matter of utility?

Of course, there are logical concerns here. And when is design ever little more than a matter of utility? Even aesthetics have utility.

I see no utility in forcing the components of a namespace into an artificial hierarchy.

Databases and application schemas are subordinate to the user's view of his or her universe.

Users and application schemas are subordinate to the database's view of its universe.

Databases and users are subordinate to the application's view of its universe.

If one has a namespace with database, user and application components, how does one arrange the components into a single sensible hierarchy? Received on Mon Jul 14 2003 - 19:36:34 CEST