Should two applications with separate release cycles share one database

Question

We have two products:

1. BI reports (Business Information)
2. Social networking

Product 'Social networking' is a web application, which allow users in a company to collaborate - in particular with regards to product 'BI reports'.

We have one database which both products share. They each have their own tables in the database, and also share some 'User management' tables.

Each product has it's own release cycle - when we release a new version of 'Social networking', we will not always release a new version of 'BI reports'.

I now have headaches regarding database upgrading/versioning, when a customer has version 'X' of 'BI reporting' and version 'Y' of 'Social networking'. Internally the database then has two versions.

I think the best idea is to split the database in two - each product get's it's own database and 'Social Networking' gets User Management information through a Web service offered by 'BI reports'. However the rest of my team think this is too much work and don't like the idea.

Has anyone any experience with regards to sharing databases between multiple applications?

Answer 1

We have a product that is made up of several different modules. Customers can pick and choose which modules are installed.

All of the modules share a core piece which handles user logins and other very common site wide features.

Complicating this is that some of the modules are dependent on others. We took a modular approach in order to easily take large chunks of code and easily build new modules.

All of that said, we have a similar situation in that each module is versioned and potentially released separately. To handle this we did two things.

First, each module is registered in a common db table with it's current revision number. It will also register any security roles and actions into the common tables. These checks are generic enough that the core can handle it. Second, each module has it's own schema inside the database. ie: module1.Table1, module2.Table2. This allows us to have the same table names across multiple modules.

When we upgrade a given module, it only impacts it's own DDL (structure/data/s'procs/views). If there is a dependency between modules, this is handled by the upgrading tool. It checks the database to see if version xyz (or better) of the related module is installed. If it is then the upgrade is allowed to continue. If not, then the upgrade aborts and tells the user they need to upgrade the other parts first.

The main thing to take away from this is the dependency check. If your modules are truly separate and only share the common security checks then it doesn't matter all that much. However, if there is some other overlap then the installer for each needs to check the versions to make sure they are compatible.

You might even provide a "complete" installer which upgrades both apps to the current level for those that are way out of sync.

Answer 2

if this is a management decision, then I would approach it like this:

1. how much time/resources does it take to manage the system as is?

2. how much time/resources will it take to rework the system into the proposed new system?

3. how much time/resources will it take to manage the system when the changes are made?

Assuming there is some resource savings by making the changes, then there should be a cutover period when there is a return on the investment. a manager would be able to decide if the length of time between now and then is worth the current expense of the effort vs other items that may need to take priority.

hth

Answer 3

I think this touches on more than release cycle - we're thinking about this quite a bit ourselves.

Our cataloging application has a BI aspect to it as well, but we're finding that the BI part might be affecting the performance of the catalog.

I mention this becuase you might find that seperate databases for the two applications might work out not only for release management but also performance. Periodic 'archives' of key data from your social-netowrking app to your BI app might give you the best of both worlds - performance in the Social app and release management.

Not sure about the shared user management aspect for you...

Answer 4

If you change a shared table you must update both apps. You can't have a separate release cycle.

This is obvious.... no?