"Daniel Jimenez" wrote:

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

This I don't understand.
If a company has to have certain data when it starts selling yet another
product, it does not make much difference (amountwise) if the data comes as
an additional DB or as an additional table. Only that an additional table in
only one database can be integrated much more elegant than an additional DB.
Maybe I haven't understood the problem on hand.

Florian