Jim Starkey escreveu:

> Roman Rokytskyy wrote:
>
>> Jim,
>>
>>
>>
>>> If I were attacking the problem, I'd make the "mega-database manager" be
>>> a separate provider and maintain it's own system tables using a local
>>> Firebird database. I'd snapshot remote table metadata at creation time,
>>> and re-validate the snapshots from time to time. I would design and
>>> implement it to be totally transparent the remote protocol and existing
>>> clients and tools. I'd also do a clean, modern, object oriented
>>> implementation.
>>>
>>>
>> Are you talking about a mega-database-manager as provider in Vulcan
>> sense? I mean that one would need to create database through that
>> provider (or register it in the config file), and later use that very
>> database to execute cross-database queries, while leaving the
>> possibility to connect to single databases for "local" table access only?
>>
>> Or do you mean something different?
>>
>>
>>
>
> No, that's exactly what I mean -- a database of databases, some local,
> some remote. It has three major functions. First, as a meta-data
> handler, mapping, where necessary, table and global field names,
> maintaining a list of known tables, and tracking local accounts, remote
> database accounts, and generally keeping track of who can see what.
> Vlad's proposal didn't handle this, putting remote authorization on
> every remote table definition. Given that Firebird system tables are
> all public, this would have compromised the security across the entire
> network. The second job of the mega-database manager is to decompose
> queries into what are known as semi-joins (a semi-join is part of the
> full join cross product fetched as a unit from a single database).
> Vlad's proposal didn't have an object declaration for remote database,
> making this more difficult. The third job of the meta-database manager
> is to merge the semi-join into a single semantically correct data stream.
>
> None of these are particularly trivial and none are optional.
>
> An on-cheap-alternative would be a local library that would take
> existing connections to various databases and handle jobs #2 and #3 in
> the client context. The local facility would require, at a minimum, a
> metadata aliasing facility, a SQL parser, an optimizer, a SQL (or BLR)
> generator, and enough of a runtime to merge semi-joins. Once you had
> that, of course, for only a little bit more work you could add a
> metadata store, account mappings, and the provider interface and get the
> sucker out of the client.

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

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

It will not allow to optimize joins (and whatever) of different
databases in the same engine.
With a good code base, I'm sure we can handle this.

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


Adriano