Adriano dos Santos Fernandes wrote:

> Your "Mega-database manager" is not good than Vlad approach IMO.
>

Your opinion is always valued. Sometime, however, facts count, too.

> It will create another "database-engine" in the provider, with
> optimizer, parser, executor, etc, etc...
>

Yes? And since the process to optimize network queries is quite
different from local queries, isn't this necessary and even desirable?
Nothing says that suitable code from the Firebird engine can't be
reused, but since the existing optimizer and runtime don't quite do what
is necessary to manage network queries, doesn't it make sense to build a
specialized engine?

> It will not allow to optimize joins (and whatever) of different
> databases in the same engine.
>

That's a strange and interesting assertion. On what is it based?

The basic idea of network optimization is to decompose a complex query
into a set of independent queries to execute at each network node
involved in the query. For efficiency, each of these queries should be
designed to give the remote engine(s) the best possible opportunity for
local optimization.

The Firebird optimizer is essentially cost based. A network optimizer
is generally heuristic based, concerning itself less with the cost of
fetch records from disk than minimizing round trips and the volume of
data transmitted.

> With a good code base, I'm sure we can handle this.
>

Undoubtedly. If you set you standards low enough, you can do almost
anything.

> And I don't see big problem with absence of metadata of foreign objects.
> AFAIU, Oracle also doesn't store it.
>
>

Perhaps you missed the discussion of metadata and tools. You may want
to review it before deciding the metadata isn't important.