Subject | RE: [firebird-support] Silly but necessary question |
---|---|
Author | David Johnson |
Post date | 2004-10-27T02:21:05Z |
To handle this problem, typically we replicate the necessary cross
reference or primitive tables across the databases in question. There
are several tools that can be used to do this, depending on the exact
nature of the processes and tables in question.
Either the owner database will have a trigger that fires the replication
process on row inserts, updates, and deletes to cause the row to be
reflected in the foreign database, or the replication will be done via a
nightly job. Apps running against the databases are constrained by
design and convention only to never change data that is replicated from
outside their particular database.
Examples might be a "common" code to "official" code translation table,
a table of allowed values for some purpose, or a partial replication of
unsecured information from a table that has both secured and unsecured
portions (information hiding in OOP terms).
reference or primitive tables across the databases in question. There
are several tools that can be used to do this, depending on the exact
nature of the processes and tables in question.
Either the owner database will have a trigger that fires the replication
process on row inserts, updates, and deletes to cause the row to be
reflected in the foreign database, or the replication will be done via a
nightly job. Apps running against the databases are constrained by
design and convention only to never change data that is replicated from
outside their particular database.
Examples might be a "common" code to "official" code translation table,
a table of allowed values for some purpose, or a partial replication of
unsecured information from a table that has both secured and unsecured
portions (information hiding in OOP terms).