> > I have posted this question in the Firebird group, but feel that it
> > may be more appropriate to post this question here.
> >
> > I am designing DB's for several applications where there is
> a lot of
> > shared data, FK's, etc. Since FireBird does not support cross DB
> > references, constraints, triggers, etc. How do people normally deal
> > with this problem when writing large complex systems with multiple
> > DB's where there exist a need to created FK's across DB's which are
> > required within triggers, constraints ,etc for the purpose of
> > insertion, deletion and updates.
> >
> > How do you attack the problem of transaction handling? Etc.
> >
> > danieL
>
> I would re-assess your need for multiple DBs. Use one instead Alan

This is not an option, unfortunatly :-(

The reason why there are multiple DB's is because there are several products
within the Company that can be sold individually. As the customer
requirements grow they are able to update the system, hence the database
requirements also grow. In our case, some customers are very small and
would never update their system to the full blown range of products (ie,
there are several products that can work independantly but share common data
when used as a complete system).

We thought about adding tables to a single database but the main argument
against this is that we can sell product A (which, for example, uses
database d_a and d_common) and then at a later time sell product B that has
database d_b and shares data from d_common. Since the content of databases
d_a and d_b are totally unrelated it does not make sense to bunch it all
into one big database. As the Company grows, and hence the range of
products sold grows, we would end up with one big ugly monster. The shared
data across multiple databases is designed to prevent corruption which may
result.

danieL
____________________________
Comvision Pty. Ltd.

www.comvision.net.au