Question

Here is my dilemma,

I am working on some SaaS using ASP.net MVC3 and SQL Server.

there will be multiple companies that user the software, each company will have multiple users. to make sure the data doesn’t accidentally become visible from one company to another I have setup the databases as individual databases for each company and then the web-servers handle everything else: UI, logic etc.

I can foresee an issue already and I need to decide how best to deal with it before it becomes a real issue. Having these multiple databases, if everything goes good this year knock on wood we could potentially get 500 clients by the end of the year. Manually syncing schemas is out of the question for obvious reasons. VS2010 has a nice SQL compare script tool that will be helpful but how should I go about making sure that all the databases are of the latest version?

Problem 2

the way the system is designed it is very modular, so the clients will be able to add little widgets and things for their particular needs which will add new tables to there specific database. so in theory each database will be a little bit different. I figure the best way to handle this is to chuck all change scripts so that you have

Core.sql 
Widget-Map.sql 
Widget-HR.sql  
etc.. 

am I correct in this line of thinking or is there perhaps a more practical way to attack this situation?

I have looked into Red-Gate SQL compare and I like it but, it still doesn’t help in the multiple database situation.

so that being the case should I just create my own tools for updating the schemas?

if so any advice, tips, links. to make this task a little less daunting would be very appreciated.

Thank you very much for any and all assistance,

A Few Source I have already read,
Migrations for Java

http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

Answer 1

Outside of an ORM that does structure upgrades, the methods break down as:

1. Compare to some DB that is considered correct. Personally I consider this risky, as I would much rather have the upgrade tied to the deploy of code, and have the db spec included somehow in the code. This is personal preference of mine.

2. Upgrade scripts. Used to be the most popular, seems to be passing out with ORM’s taking more hold. Basically for any particular release you’ve got an “install” script that builds from scratch, and a second set of scripts that handle all incrementals “From_x.y.z_to_a.b.c” kind of thing. Pro: Simple to understand. Con: doubled code, extremely major PITA when the 7th script of 17 fails.

3. Dictionary or schema based upgrades. Probably the least popular in that outside of myself, I know nobody that does it 🙁 OK, maybe that’s an exaggeration. PHP Doctrine has something like this. The idea is some tool compares the schema to the existing database and brings the schema current. Pro: single schema file (or files), no doubling of code, best way to guarantee the upgrade will produce the database you expect in the shortest time. Con: (almost) nobody does it, dearth of tools.

I have a tool that does this, and ought to work on MS SQL, but I’m only testing on Postgres right now, so I won’t post a link cuz I don’t want to waste your time.