我正在开发一种定制的CRM解决方案，它将通过Web / SaaS模型销售。我预计有数百或数百个客户使用此解决方案。我将使用MS SQL作为数据库引擎。
选项1是拥有一个数据库，并在表上包含一个TenantId列，一个合适的索引，并在每个数据库访问时使用'where tenantId = {...}'。
选项2是为每个客户提供一个单独的数据库，避免使用TenantId和where子句。
我预计每个客户将拥有数十万条记录，而不是数百万条。
正如我所看到的，无论我选择哪种选项，都会有数据页总数。这个决定似乎集中在SQL是否更好地管理多个DB，或者是一个具有TenantId和索引的DB。最初，该解决方案将在单个数据库服务器上运行，但最终将转移到SAN。
有人对此有任何意见吗？
答案 0 :(得分：4)
有一篇有趣的MSDN文章，标题为Multi-Tenant Data Architecture，您可能想要查看。作者简要分析了某种方法可能比另一种方法更合适的地方：
的数量，性质和需求 您期望服务的租户都会受到影响 您的数据架构决策 不同的方法。以下一些 问题可能会让你偏向更多 孤立的方法，而其他人可能 偏向于更加共享 方法
您有多少潜在租户 期望目标？你可能无处可去 接近能够估计 有权使用的预期用途，但是 从数量级来考虑： 你在为它建立一个应用程序吗？ 数百个租户？成千上万的？十 成千上万？更多？你越大 期待您的租户基础， 你更有可能想要考虑 一种更为共享的方法。
您期望多少存储空间 平均租户的数据占用？ 如果你期望一些或所有租户 存储非常大量的数据， 可能是单独的数据库方法 最好。 （的确，数据存储 要求可能会迫使你采用 无论如何，单独的数据库模型。如果是这样， 设计它会容易得多 应用程序的方式 开始而不是移动到 稍后单独的数据库方法。）
您有多少并发最终用户 期望普通租户支持？ 数字越大，越多 适当的更孤立的方法 将满足最终用户的要求。
您是否希望提供任何每位租户 增值服务，如 每租户备份和还原 能力？这样的服务更容易 通过更孤立的提供 方法
请注意，“共享方法”是选项1，“隔离方法”是选项2，在您的情况下。前两点你不会偏向任何一方，所以我认为我的决定将基于最后两点。
答案 1 :(得分：0)
如果您不必在租户之间链接数据，那么您最好拥有多个数据库。维护更容易，设置更容易，性能也会更好。 当在一个表中拥有来自多个租户的数据时，表锁和大表搜索查询可能并且很可能会减慢您的解决方案。
共享一个数据库的唯一原因我会看到你是否拥有非常多的客户端以及每个客户端的行数非常少。