但也有一些企业
当然，他们担心他们的数据可能会
受到损害，所以我们正在评估
其他解决方案。
这是不幸的，因为客户有时会误以为只有物理隔离才能提供足够的安全性。
MSDN 有一篇有趣的文章，标题为多租户数据架构 http://msdn.microsoft.com/en-us/library/aa479086.aspx，您可能想要检查。这就是作者如何解决对共享方法的误解的：
一个常见的误解认为
只有物理隔离才能提供
适当的安全级别。在
事实上，数据存储使用共享
方法还可以提供强有力的数据
安全，但需要使用更多
复杂的设计模式。
至于技术和业务方面的考虑，本文对某种方法可能比另一种方法更合适的地方进行了简要分析：
的数量、性质和需求
您期望服务的租户都会受到影响
您的数据架构决策
不同的方式。以下一些
问题可能会让你更倾向于
孤立的方法，而其他人可能
使你倾向于更加共享的
方法。
您预计有多少潜在租户？你可能无处可去
接近能够估计
预期使用权威，但是
从数量级的角度思考：
您正在构建一个应用程序吗
数百名租户？数千？十
数千个？更多的？你越大
期望您的租户群是
您更有可能想要考虑
更加共享的方法。
您预计租户的数据平均占用多少存储空间？
如果您希望部分或全部租户
存储非常大量的数据，
单独的数据库方法可能是
最好的。 （事实上，数据存储
要求可能会迫使您采用
无论如何，单独的数据库模型。如果是这样，
设计起来会容易得多
应用程序从
开始而不是移动到
稍后采用单独数据库方法。）
您期望租户平均支持多少个并发最终用户？
数字越大越多
采取更加孤立的方法
将满足最终用户的要求。
您是否期望提供任何针对租户的增值服务，例如
按租户备份和恢复
能力？这样的服务比较方便
通过更孤立的方式提供
方法。
UPDATE:进一步更新预期租户数量。
对于大多数（如果不是全部）场景，预期的租户数量 (10k) 应排除多数据库方法。我认为您不会喜欢维护 10,000 个数据库实例，并且每天必须创建数百个新实例的想法。
仅从该参数来看，共享数据库、单模式方法似乎是最合适的。事实上，每个租户只需存储大约 50Mb，并且不会有每个租户的附加组件，这使得这种方法更加合适。
上面引用的 MSDN 文章提到了三种解决共享数据库方法安全注意事项的安全模式：
- 可信数据库连接 http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tdc
- 租户视图过滤器 http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tvf
- 租户数据加密 http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_tde
当您对应用程序的数据安全措施充满信心时，您将能够为您的客户提供服务水平协议 http://en.wikipedia.org/wiki/Service_level_agreement为数据安全提供强有力的保障。在 SLA 中，除了保证之外，您还可以描述为确保数据不受到损害而将采取的措施。
更新2：显然微软的人移动/制作了一篇关于这个主题的新文章，原始链接已经消失，这是新的链接：多租户 SaaS 数据库租赁模式 https://learn.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns（向谢·克尔致敬）
