http://ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx
Continuing on the multi tenancy theme, let us talk about the actual physical structure of the data store. In general, you have two basic options.
The TenantId column and separated data stores. The TenantId is simply adding a column to all the columns, showing what tenant the row belongs to.
The separate data store calls for a much higher level of separation, where there is no shared storage for the tenants.
There are variation on those, such as having separation in the schema level instead of DB level, etc, but they all end up being down to one of those choices.
The TenantId approach allows you to use a single DB for the entire application, potentially reducing costs for managing the environment. It is also the easiest to explain, we just filter by TenantId and that is it!
It comes with a whole set of problems that is related to that decision, however:
Isolation - You have to actively do filtering all the time. This has major issues on your code. And now, tacking TenantId = @CurrentTenant at each query is not going to be sufficient. Consider the case of joins in such an environment, you are likely to get a filter only on the end result, after it was joined already. And that is just one example.
Backup - The backup strategy that you have for this scenario sucks. Basically, you have to roll your own.
Customer copy of the data - Going back to the backup strategy? You can't just hand the customer the backup. You have to dump the data out, and write something that writes it back in, and it has to be fast.
Security - you have to let all tenants access the data, security is in the app logic level.
Extensibility - in a shared environment it is hard to do a lot of extensibility in the data, because each client is stepping on each other toes.
As you probably gathered, I strongly suggest going with the separate model. Now our management strategy is dealing with the connection string. Isolation is built in and doesn't require any , for backup you have the vendor tools, and giving the customer its own data is trivial, just send him the backup file. Security is easy, a tenant can access only their DB, and extending this is much easier, because each tenant has their own walled garden to play with.
Continuing on the multi tenancy theme, let us talk about the actual physical structure of the data store. In general, you have two basic options.
The TenantId column and separated data stores. The TenantId is simply adding a column to all the columns, showing what tenant the row belongs to.
The separate data store calls for a much higher level of separation, where there is no shared storage for the tenants.
There are variation on those, such as having separation in the schema level instead of DB level, etc, but they all end up being down to one of those choices.
The TenantId approach allows you to use a single DB for the entire application, potentially reducing costs for managing the environment. It is also the easiest to explain, we just filter by TenantId and that is it!
It comes with a whole set of problems that is related to that decision, however:
Isolation - You have to actively do filtering all the time. This has major issues on your code. And now, tacking TenantId = @CurrentTenant at each query is not going to be sufficient. Consider the case of joins in such an environment, you are likely to get a filter only on the end result, after it was joined already. And that is just one example.
Backup - The backup strategy that you have for this scenario sucks. Basically, you have to roll your own.
Customer copy of the data - Going back to the backup strategy? You can't just hand the customer the backup. You have to dump the data out, and write something that writes it back in, and it has to be fast.
Security - you have to let all tenants access the data, security is in the app logic level.
Extensibility - in a shared environment it is hard to do a lot of extensibility in the data, because each client is stepping on each other toes.
As you probably gathered, I strongly suggest going with the separate model. Now our management strategy is dealing with the connection string. Isolation is built in and doesn't require any , for backup you have the vendor tools, and giving the customer its own data is trivial, just send him the backup file. Security is easy, a tenant can access only their DB, and extending this is much easier, because each tenant has their own walled garden to play with.
2178
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
