On Thursday 02 August 2007 12:38, Pavel Cisar wrote:

> Alex Peshkov wrote:
> >> It has a drawback that it doesn't allow any smart and magical internal
> >> optimizations when the external data source happens to be the Firebird
> >> server or another database at the same server. But personally I see it
> >> more as advantage, as I think that any attempt to get smart and create
> >> such optimizations is either doomed to fail
> >
> > Pavel, QLI does it :)
>
> I know, but only for FB databases. And it's not always optimal either
> (but better than nothing).

As soon as we agree to use external adapters as providers, it will make no
difference.

> >> or would bite us big time at
> >> the end (external data sources should be rather used as escape routes,
> >> not as basic building blocks).
> >
> > This is what should be taken into an account.
> > On the other hand, imagine, please. One common database with very big
> > data (i.e. houses/streets/towns all over the world). And a lot of others
> > are linked to it. I want to:
> >
> > select local_table.*, remote.adr.text
> > from local_table
> > join remote.adr on local_table.adr = remote.adr.id
> > where local_table.id between 100 and 110
> >
> > It would be really sad to read ALL external table when I really need not
> > more than 11 records.
>
> 1. It could work when all databases are at the same Firebird server. I
> can't imagine how you can optimize it up to user's expectations when
> servers are at different FB servers, or belong to different one (DB2 for
> example).
>
> 2. This only one optimalizable case (multiple databases at single FB
> server) could be easily replaced by single database with name spaces
> support without poisoning the optimizer and SQL syntax.
>
> 3. If we'll try to implement what you described for as much servers and
> use cases as possible, we'll in fact try to change Firebird into
> Federated Database Server, which idea was considered stupid by everyone
> except IBM. Personally, I think that federated databases are
> "interesting" and could make interesting Firebird fork (it would destroy
> the core idea behind Firebird: to be slick, small, fast and robust
> engine, so I wouldn't have a nerve to do it in HEAD), but I wouldn't
> dare to delve into such grand experiment without having significantly
> more resources at our disposal to have a chance to do it "right" (even
> IBM with their resources wasn't so far very successful).
>
> 4. External data sources are tools to *bridge* between (typically
> heterogeneous) systems, *not blend* them into one. It's a band aid to
> make your various legacy and new systems to work together (until you'll
> come with better solution).

Today we can't bridge even with database on the same server. :-(

But if we follow Jim's suggestions (I do not see reasons not to do it), the
only thing we will need to add new type of datasources is to implement
external adapter and connect it to Y-Valve. I do not want to say that
implementing 50-60 API entrypoints using foreign API is trivial, but on the
other hand - nothing unreal.

And please take into an account that access to our own databases will be
present at once, with maximum available support.