One question we will be looking at is a fairly key one: as we build our Service Oriented Business App, and therefore drive the creation of services, we will be taking our nice, app-specific, logical data model and breaking it up to show which parts are in support of which services.
Do we then break those parts up into different actual databases? Alternative: we could simply create different sets of tables within the same db (a practice that the dev team is already familiar with).
Let's look at both sides.
- If the services are truly independent, they may need to scale seperately. They may need to move to other locations. They may need to change structure independently. All good reasons to seperate.
- On the other hand, if I have two databses, and make backups of them at 3:02am and 3:04 am, and the server hard drive goes down at 10am, prompting a restore, do I risk creating an inconsistent database situation because of the two-minute gap? Do I add complexity in database operations by creating the hard line between my service databases?
- If the services are designed well, there should be no cause for a single transaction that adds data under two different services.
- There should not need to be direct referential integrity between any two independent service databases.
I'm leaning towards forging a hard line. I'd like to know what you think.