At 04:23 PM 6/5/03 -0300, Daniel Rail wrote:

>Hello Marius,
>
>Thursday, June 5, 2003, 3:18:05 PM, you wrote:
>
>MP> sorry for the first email
>MP> What i want to ask is about connecting to muliple
>MP> databases in interbase , it is possible to be
>MP> implemented into firebirdsql ?
>
>I've asked that question myself and many others, and still I couldn't
>find those discussions. I know Ann gave a good point as to why it
>wasn't implemented yet.
>
>But, I think with the introduction of aliases in FB 1.5, it might be
>one small step forward for this feature to be implemented. But,
>there's a lot more work to do to get there. If my memory serves me
>well, the biggest hurdle in cross database selection is to be able to
>get the proper optimization of the data retrieval and proper
>synchronization of the data retrieval between the databases, and
>having a common cache between the databases for the result set.
>
>So I believe that the task at hand is not small and would require
>quite some work and a very good knowledge of the engine.

The short answer is no. The longer answer is that an unimplemented part of
the grand architecture was a beast called the "mega-database manager."

The mega-database manager is a data manager that sat under the Y-valve
parallel to the engine, remote interface, and gateways. The mega-database
manager, in essence, was a virtual database defined in terms or two or
more database, each of which was independently administrated, The
mega-database manager managed virtual database definition, consistent
meta-data presentation, communication, request decomposition, request
execution/synchronization, and two-phase commit.

The original concept was, of course, designed around BLR. Since there is
fairly convincing evidence that BLR is unlikely to kill off SQL in the very
near
future, any serious thinking about the mega-database manager should be
SQL centric, which, unfortunately, precludes any significant reuse of existing
engine code.

All in all, the mega-database manager is probably the same order of magnitude
in size and complexity to the current engine, though the available of large
amounts of memory for meta-data caching would simplify implementation.
The really hard part, however, comes with the realization that 85% of the
mega-database manager is not Interbase/Firebird specific, and with just a
little
bit more work, could work with an arbitrary ODBC/JDBC (pick one) complaint
datamanagers, giving it an independent existence, and changing the economics
drastically. And, unfortunately, probably tripling the size * complexiity *
reliability. Oh well.

da Wolf