> > > In my mind the point of the "database" concept is to
> provide a domain
> > > within which custom datatypes and functions are available.
> >
>
> AFAIK few users understand it and many users have wondered
> why we couldn't issue cross "database" queries.
Imho the same issue is access to tables on another machine.
If we "fix" that, access to another db on the same instance is just
a variant of the above.
>
> > Quoth SQL99:
> >
> > "A user-defined type is a schema object"
> >
> > "An SQL-invoked routine is an element of an SQL-schema"
> >
> > I have yet to see anything in SQL that's a per-catalog
> object. Some things
> > are global, like users, but everything else is per-schema.
Yes.
> So why is system catalog needed per "database" ?
I like to use different databases on a development machine,
because it makes testing easier. The only thing that
needs to be changed is the connect statement. All other statements
including schema qualified tablenames stay exactly the same for
each developer even though each has his own database,
and his own version of functions.
I have yet to see an installation that does'nt have at least one program
that needs access to more than one schema.
On production machines we (using Informix) use different databases
for different products, because it reduces the possibility of accessing
the wrong tables, since the syntax for accessing tables in other db's
is different (dbname[@instancename]:"owner".tabname in Informix)
The schema does not help us, since most of our programs access
tables from more than one schema.
And again someone wanting Oracle'ish behavior will only create one
database per instance.
Andreas
