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

What benefits it have over including this "manager" into core engine ?
This manager will reuse most code parts so why not extend existing engine ?
Why do you need to store (make persistent) extern metadata ?

Is it will be possible to query remote data from local stored procedure ?
If yes, how local data will be joined with remote and where this will handled ?
If no, this is show stopper

> >> I would design and
> >> implement it to be totally transparent the remote protocol and existing
> >> clients and tools.

Agree

> >> I'd also do a clean, modern, object oriented implementation.

Of course

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

Why metadata handler must be outside of local engine ?

> Vlad's proposal didn't handle this, putting remote authorization on
> every remote table definition.

??? Where do you read this ???

> Given that Firebird system tables are
> all public, this would have compromised the security across the entire
> network.

??? Where do you read this ???

And how mega-database-manager's database helps you to not
compromise the security ? It will implement not public system tables ?

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

Yes

> Vlad's proposal didn't have an object declaration for remote database,
> making this more difficult.

I don't understand this. Explain please

Regards,
Vlad