Subject | Re: [IB-Architect] Proxy Query ? |
---|---|
Author | Ann W. Harrison |
Post date | 2001-03-07T00:01Z |
At 12:49 AM 3/7/2001 +0100, Darko Prenosil wrote:
major effort. First, we'll need to agree on language extensions
and direction. One alternative is to allow access to several
databases but restrict any specific query to one database. Another
is to allow databases to be mixed in a query, but keep each select
expression restricted to one database. The best, and hardest, is
to allow free reference to multiple databases.
The hard part ... well, there are several ... but the hardest part
is cross database optimization. We have a lot of work to do on
the single database optimization - and the complaints there demonstrate
how painful bad optimization is. For that reason, I would tend to
make the first implementation follow the first or second model.
Even if we go to the third model, cross-database constraints (and
procedures, and triggers) is a problem that merits much discussion.
How do we handle the case of access to one database when the other
is not available? What happens if one database is moved or renamed?
Yes, aliases help here, but I'm so used to the idea that a database
is a single entity that putting permanent links between databases
really bothers me.
Regards,
Ann
www.ibphoenix.com
We have answers.
>I got only few more question :Cross database access in SQL is an important feature, but also a
> How high on the Firebird to do list is this subject ? (Unfortunately I'm
>not programmer good enough to do it my self.).
major effort. First, we'll need to agree on language extensions
and direction. One alternative is to allow access to several
databases but restrict any specific query to one database. Another
is to allow databases to be mixed in a query, but keep each select
expression restricted to one database. The best, and hardest, is
to allow free reference to multiple databases.
The hard part ... well, there are several ... but the hardest part
is cross database optimization. We have a lot of work to do on
the single database optimization - and the complaints there demonstrate
how painful bad optimization is. For that reason, I would tend to
make the first implementation follow the first or second model.
Even if we go to the third model, cross-database constraints (and
procedures, and triggers) is a problem that merits much discussion.
How do we handle the case of access to one database when the other
is not available? What happens if one database is moved or renamed?
Yes, aliases help here, but I'm so used to the idea that a database
is a single entity that putting permanent links between databases
really bothers me.
Regards,
Ann
www.ibphoenix.com
We have answers.