跨服务器管理身份/主键

Question

我正在设计一个需要支持复制的新数据库，但我一直在决定选择什么作为我的主键。

在我们当前的主键数据库中，我们使用两个 int 列，第一列是标识，另一列用于描述在哪个服务器上插入行。现在我想避免使用两列作为主键，而只使用一列。到目前为止，我有两种方法：

1. 为我的主键使用 GUID

   这将确保在任意数量的服务器上始终存在唯一的密钥。我不喜欢这个，GUID 的大小是 16 字节，当用于跨多个表的外键时，它会浪费空间。而且写查询的时候用起来比较麻烦，查询起来也比较慢。

2. 使用 int 或 bigint，并为每个服务器上的每个表手动指定种子和增量值。例如，如果有两台服务器，第一台服务器上的 X 表将从编号 1 开始，而在第二台服务器上，它将从编号 2 开始，每个服务器都将递增 2。所以会有 (1,3,5,. ..) 在第一台服务器上，(2,4,6,...) 在第二台服务器上。这种设计的好处是在编写查询时更容易使用，速度很快，并且为外键使用的空间更少。糟糕的是，我们永远不知道将运行多少台服务器，因此很难判断增量值是多少。此外，管理服务器上的架构更改也更加困难。

管理多台服务器的最佳做法是什么？在这种情况下，最好的方法是什么？

Answer 1

你的问题很好，而且经常被问到。

从维护的角度来看，我绝对会选择 GUIDS。他们在那里是有原因的。 在某个地方，您可能会遇到移动和重新复制数据的复杂操作，然后其他选项可能会使它变得比需要的复杂一点。

这里有一个关于各种选项的非常好的简短阅读：

http://msdn.microsoft.com/en-us/library/bb726011.aspx

至于复制部分 - 如果处理得当，复制就不会真正令人头疼。

Answer 2

我敢于建议不要完全复制 :) 这肯定比有趣更痛苦。如果您负担得起，请查看Sync framework。

至少可以说，玩弄身份并不灵活。考虑添加移动服务器。身份插入、不同的架构等等。

如果您使用 newsequentialid() 作为默认值，则 GUID 可以用于集群键。它有点大（一些位），但它一劳永逸地解决了麻烦:)

我要采用的方法是拥有一个仅与数据库上下文相关的 int 身份集群键。然后添加一个 GUID 列，这对同步上下文有意义。用 rowversion 列填充它，以查看准备好同步的内容。

Answer 3

更新：

找到了更简单/手动的方法here。涉及使用 NOT FOR REPLICATION 和您在 cmets 中提到的惊人的身份种子值。

原文：

您最好的选择类似于列出的第二个选项。为复制发布者和订阅者实例分配身份范围，然后开启自动范围管理。

This article 讨论了在复制中管理身份列的选项，enabling identity range management 在这里讨论。

由于您不知道复制池中有多少服务器，您可能需要定期重新配置文章属性。