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

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

best regards
Pavel Cisar
IBPhoenix