Separating application'' s database into two, best approach?

  • I have a number of Web applications which are all used by companies within one group. Each one of these applications stores information about customers in their own database, and it's come to light that it would be useful to share this data between all the companies.

    The obvious choice seems to be to have one central database for customer information, and alter the applications to use this database, alongside their own. The information only to share is all in one table.

    I'm interested to know what people think would be the best approach to do this. At the moment each application calls stored procedures to do all operations on the data, so everything is nicely isolated.  One of the applications is large, and the customer information is used throughout so an approach which requires the least amount of recoding would be of benefit.

    I'm currently thinking of going with views linked to the new customer database, to replace the existing customer tables. However, I've never come across this being done before and am not sure if it's the best approach. If anyone has any other ideas, I'm all ears.

    Cheers,

    Stuart Rider.

  • I think your approach is ok.

    >I'm currently thinking of going with views linked to the new >customer database, to replace the existing customer tables.

    if all the databases are on one server you should not face too many problems. But i think you will have problems like when you want to scale on of the db and move it to another server.

    the other problem you will likely face is when you want to validate the customer no. which i guess will employ triggers.

    So you have to probably plan with replication in mind for the customer db.


    Everything you can imagine is real.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply