We've two items:

  1. BI reviews (Business Information)
  2. Social media

Product 'Social networking' is really a web application, which permit customers inside a company to collaborate - particularly in relation to product 'BI reports'.

We've one database which both items share. Both get their own tables within the database, as well as share some 'User management' tables.

Each product has it's own release cycle - whenever we to produce latest version of 'Social networking', we won't always to produce latest version of 'BI reports'.

Now i have head aches regarding database improving/versioning, whenever a customer has version 'X' of 'BI reporting' and version 'Y' of 'Social networking'. Internally the database then has two versions.

I believe the very best idea would be to split the database in 2 - each product get's it's own database and 'Social Networking' will get User Management information via a Web service provided by 'BI reports'. Nevertheless the relaxation of my team think this really is an excessive amount of work and do not like the thought.

Has anybody any experience in relation to discussing databases between multiple programs?

if this sounds like an administration decision, i quickly would approach it such as this:

  1. the length of timeOrassets will it decide to try manage the machine out of the box?

  2. the length of timeOrassets does it decide to try rework the machine in to the suggested new system?

  3. the length of timeOrassets does it decide to try manage the machine once the changes are created?

Presuming there's some resource savings by looking into making the alterations, then there must be a cutover period when there's coming back around the investment. a supervisor would have the ability to determine if the amount of time between occasionally may be worth the present cost of your time and effort versus other products that might need to take priority.

hth

There exists a product that's comprised of a number of different modules. Clients can select which modules are installed.

All the modules share a core piece which handles user logins along with other common site wide features.

Further complicating this really is that a few of the modules are determined by others. We required a modular approach to be able to easily take large portions of code and simply build new modules.

All nevertheless, there exists a similar situation for the reason that each module is versioned and potentially launched individually. Additional we did a couple of things.

First, each module is registered inside a common db table with it's current revision number. It will likewise register any security roles and actions in to the common tables. These inspections are generic enough the core are designed for it. Second, each module has it's own schema within the database. ie: module1.Table1, module2.Table2. This enables us to achieve the same table names across multiple modules.

Whenever we upgrade confirmed module, it only impacts it's own DDL (structure/data/s'procs/sights). If there's an addiction between modules, this really is handled through the improving tool. It inspections the database to ascertain if version abc (or better) from the related module is installed. If it's then your upgrade is permitted to carry on. Otherwise, then your upgrade aborts and informs the consumer they have to upgrade another parts first.

The primary factor to consider from this is actually the dependency check. In case your modules are truly separate and just share the most popular security inspections it does not matter that much. However, if there's another overlap then your installer for every needs to determine the versions to make certain they're compatible.

You may even give a "complete" installer which upgrades both applications to the present level for individuals which are way to avoid it of sync.

I believe this touches on a lot more than release cycle - we are considering this a great deal ourselves.

Our cataloging application includes a BI aspect to it too, but we are discovering that the BI part may be affecting the performance from the catalog.

I mention this becuase you will probably find that seperate databases for that two programs might exercise not just for release management but additionally performance. Periodic 'archives' of key data out of your social-netowrking application for your BI application might provide you with the better of both mobile phone industry's - performance within the Social application and release management.

Unsure concerning the shared user management aspect for you personally...

Should you change a shared table you have to update both applications. You cannot possess a separate release cycle.

This really is apparent.... no?