【发布时间】：2011-04-20 15:07:29
【问题描述】：
我们开发的服务是为每个客户用户都可以预约的。 是否有策略 - 每个客户端的数据库（MS SQL SERVER）中的表是正确的？
我们认为这种策略简化并排除了复杂的表锁定。
【问题讨论】：
标签： sql-server-2008 locking optimistic-locking pessimistic
【发布时间】：2011-04-20 15:07:29
【问题描述】：
听起来您正在尝试构建多租户应用程序。我不会推荐每个客户一张桌子。相反，我会推荐以下两种解决方案之一：
将所有客户（租户）的数据集成到相同的表中，并按标识符分隔。换句话说，每个顶级表都有一个名为“ClientId”或“TenantId”的外键，可以识别和分隔每个客户端的数据。这种方法的缺点是数据库变得更大更快，而大型数据库管理较小的数据库更加复杂。此外，开发人员构建的查询可能会忘记过滤 ClientId，而一个客户端会看到另一个客户端的数据。
每个客户端一个数据库。如果客户端将托管自己的应用程序，如果每个客户端的数据大小存在很大差异，或者如果客户端希望绝对保证数据分离，这是一种更极端的解决方案，但很有用。
【讨论】：
-
我认为外键的情况不适用，因为一张表最多有 256 个限制。另一方面，我们应该为每个客户端存储一个包含数据的表。因为在并行工作的情况下，许多用户（100-1000）可以访问一张表；如果每个客户一张桌子，它将是 1-10 个用户。
-
@Alexandr - 嗯？每个顶级表中都会有 一个 外键列来引用客户表。
-
@Alexandr - 我绝对不建议为每个客户添加 FK 列。这是没有意义的，没有标准化，也没有必要。相反，每个顶级表将包含 所有 客户端的数据，您可以通过单个列将一个客户端的数据与另一个客户端的数据区分开来，该列是客户端表的 FK。
-
@Alexandr - 例如，假设我们的系统正在存储业务合作伙伴。我们的 BusinessPartners 表中包含适用于该实体的属性（姓名、地址、电话等）和另一个名为“TenantId”或“ClientId”的列，这将使我们能够将一个客户的业务合作伙伴与另一个客户区分开来。
-
好的，我们可以存储客户，但我的意思是当我们为所有客户拥有大量数据时的结构。是的，我们可以将它存储在一张表中，但我们将面临许多锁定/阻塞的副作用。我们不想为每个表拆分每个客户端的数据，并将对表的引用存储在单独的表中。例如，列 [pkClientID, TableName] - 数据 - [1, dbo.tblClient_1], [2, dbo.tblClient_2],...[n, dbo.Client_N] 而不是表 dbo.Client_All 数据。