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

I could not agree more on anything on earth than on this !

When someone comes to the point where such cross-database access is required
it just means the problem is ill-defined. Those multiple databases should
have been combined in a single DB ! Let me push the idea to its (stupid)
limit : let's offer a full third-model cross-database model, add a
restriction of one table per database (as you would have cross-triggers,
cross-constraints and the like you do not need anymore suport for multiple
tables in a DB, as you have all the facilities cross-DB), and call this
'dBase3000'. Should be a best-seller. :-)

Today InterBase/FireBird offers a very nice cross-database access from the
client side, through transactions (on the server side) which can span
multiple database connections. I will personally always vote that this is
well architectured, simple, usefull and enough for the occasionnal cases
where a cross-database workflow should occur.

____________________________________
Olivier Mascia, om@...
T.I.P. Group S.A., www.tipgroup.com


We may not always have answers,
though we're seldom short of ideas ;-)

----- Original Message -----
From: "Ann W. Harrison" <aharrison@...>
To: <IB-Architect@yahoogroups.com>
Sent: Wednesday, March 07, 2001 1:01 AM
Subject: Re: [IB-Architect] Proxy Query ?


> At 12:49 AM 3/7/2001 +0100, Darko Prenosil wrote:
>
> >I got only few more question :
> > How high on the Firebird to do list is this subject ? (Unfortunately
I'm
> >not programmer good enough to do it my self.).
>
> Cross database access in SQL is an important feature, but also a
> 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.