| Subject | Re: [Firebird-Architect] RFC: Cross database queries |
|---|---|
| Author | Jim Starkey |
| Post date | 2007-08-08T14:54:02Z |
Roman Rokytskyy wrote:
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.
> Jim,No, that's exactly what I mean -- a database of databases, some local,
>
>
>> 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?
>
>
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.