May 30, 2002 at 7:45 am
I am sugesting modifying our schema from 130 seperate database to one database (easier to maintain and add new clients). We were using identy colums for unique indexes, but now I need to use client number and a identity type. I could just read whats there add one, but want to ensure two people dont get same number. Is there any reasons why using seperat databases would be better?
May 30, 2002 at 9:23 am
We use separate db's at work. There are a couple perceived advantages. One is that when we lose a client we can "archive" the whole db quickly and easily. Another is that we can reassure our clients that there data is kept distinct from our other clients - a big sales point it seems. The final point is that with separate db's you have the option to tailor index plans and even schema if you need to (though different schemas are generally bad).
I've had as many as 250 with the same schema, which makes applying schema changes a little more complicated than if you had one db! Once you get used to it I don't know that there is much difference. Hard to vote against all the data in one db though. With separate db's every maintenance task requires a loop, every select to check for a problem requires a loop, etc. Replication was a big problem for a while - try running 250 log readers!
You also have to look at what it will cost to change and what you will save from the change. If you're early in the life cycle I'd say do it, otherwise will probably be cost prohibitive.
Andy
Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply