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