Subject | Re: [Firebird-Architect] External Data Sources |
---|---|
Author | Jim Starkey |
Post date | 2004-04-30T02:39:30Z |
Leyne, Sean wrote:
Most of the engine and all of the tools are dependent on the system
tables for metadata. With extreme effort, the primary system tables
(RDB$RELATIONS, RDB$FIELDS, RDB$RELATION_FIELDS) could be coersed to be
unions of hard tables and dynamic metadata extracted from external data
sources. But I seriously doubt the investment would reap commensurate
returns. An external table declared as more or less a select statement
against a named external data source could be easily refreshed (if
necessary) at a small cost of a full blown heuristic variants on the
core system tables. The path of least resistence is to populate the
existing system tables with a snapshot of the external data source.
Nothing would require that the external data source return anything but
the closest approximation of the current external datatypes, but the
Firebird system tables would reflect the state of the external data
source at the time of declaration. Not perfect, but the effects of
stale metadata are worst an annoyance, and at best inconsequential.
If somebody has a beast clever way to do a runtime merge of hard
internal metadata and soft external metadata, I'm all ears.
>Are you suggesting that there would be persisted entries in theYes.
>RDB$Fields table (and the like) for the external tables?
>
>
>
Most of the engine and all of the tools are dependent on the system
tables for metadata. With extreme effort, the primary system tables
(RDB$RELATIONS, RDB$FIELDS, RDB$RELATION_FIELDS) could be coersed to be
unions of hard tables and dynamic metadata extracted from external data
sources. But I seriously doubt the investment would reap commensurate
returns. An external table declared as more or less a select statement
against a named external data source could be easily refreshed (if
necessary) at a small cost of a full blown heuristic variants on the
core system tables. The path of least resistence is to populate the
existing system tables with a snapshot of the external data source.
Nothing would require that the external data source return anything but
the closest approximation of the current external datatypes, but the
Firebird system tables would reflect the state of the external data
source at the time of declaration. Not perfect, but the effects of
stale metadata are worst an annoyance, and at best inconsequential.
If somebody has a beast clever way to do a runtime merge of hard
internal metadata and soft external metadata, I'm all ears.