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