As promised here is the trail I made while reading up on Multi-Tenancy.
One of the initial architectural decisions that I need to make is whether to run as a single-tenant ( One database per client ) or a multi-tenant ( Each database has many clients ). My initial thoughts were multi-tenant, to save on database admin overheads and overall running costs. I didn’t really know what to base my decision on though. So over the course of a couple of days. I did a lot of reading and listening.
StackOverflow is a great place to start for reading because the best answers are based on the experiences of real developers.
Those questions also lead me to to the Stack Overflow podcast, which gives us Spolsky’s point of view. At this point I’m erring back towards one database per client.
The wikipedia article is great summary once you know the name of what you are looking for.
Screencast from salesforce; if they can do it with that many users, multi-tenancy on my scale would be a cinch.
Some slides from linked in:
MSDN often has some really good articles, this one is not too SQLServer specific.
The table of “Days between Failure” is putting me right off multiple databases.
Side-tracked into row level security, but I don’t think this is much use to me.
The outcome? Multi-tenancy is too useful a feature to ignore, so I will definitely be starting off with all clients going into one database. I may spin off a separate database for shared data ( e.g. Users ) but I’ll have to re-examine that later.
However, I’m certain that for some customers multi-tenancy won’t be good enough. So at a later date I will offer single tenant solutions, either for self-hosting or as a premium feature for hosted.