Share Data Between Databases

Question

I'm looking at developing an application which will be used by several (5-8) different institutions, all related to each other but operating as independent businesses. Although each institution will use the same application, they will each have their own separate database in the back end. The business have already been operating for many years, and historic data will need to be migrated to the new databases.

For almost all intents and purposes, the data for these institutions is unrelated. However, I would like to be able to have a link between clients in the different databases say, for example, to ensure that a client with bad debts at one institution doesn't go and open an account with another without any kind of warning.

The only solution I can think of is to have a central database, much smaller and simpler than the ones powering the applications, with a Person table. When a new client is being created in any of the discrete databases a lookup is performed against this central table, based on name and postal code, to suggest possible matches.

If the user sees an existing 'person' who seems to match the client they're setting up, they select that matching record from a list and the unique Person ID from the central table is added to a PersonID column in the Client table of the institution's own database. If no match is found, a new record is created in the central Person table first, with the Stored Procedure returning the new Person ID, which would again be added to the PersonID column in the institution database's Client table.

In essence, each Client table in each database has a Foreign Key field, but this isn't actually defined in the database because the table with the primary key (the Person table) is in a different database.

Does this sound like a reasonable solution? Can anyone suggest a better way? I can see problems with this method, such as "What do you do if a client's details are updated in one of the institution databases - do you populate the changed upwards?" But I can't think of a better alternative.

Answer 1

The better approach is to have one database for the entire application which can be replicated an be in-sync(Master-Master Replication). Read here

As far as the database design it's easier to have a multi-tenant architecture where every institution is using the same database but distinguished by an institution_id. this way you can ensure user uniqueness through out the organization and at the same time manage schema changes updates and etc.