嗯，我确定之前已经问过这个问题，但我还没有找到一个可靠的答案。我正在创建一个解决方案，涉及远程办公室通过Web服务将数据上传到一个主数据库。 基本上，每个办公室都有一个Windows服务，每1小时左右运行一次，将任何新数据提取到数据集中，通过http连接到服务器，然后上传数据集。然后服务器导入数据，一切都很顺利。理论上它应该有效。右。
并非如此，因此每个办公室都有一个唯一的OfficeID，由服务器提供给它，以使它们在服务器上保持唯一。起初我以为我已经破解了它，直到我意识到自动增量PK的问题。您看，所有远程办公室都已有现有数据，并且所有表都具有自动增量PK和所有相关约束。具有OfficeID的Root / Parent表没有问题，因为它已经是唯一的，问题在于外键，因为当它们到达服务器时，它们将具有NewID，因此与子节点的关系将丢失。
目前我只有2个解决方案。
选项1看起来更容易实现，因为它对我的工作较少，但我不知道sql的性能和数据完整性将是一个问题，因为无法强制执行约束。选项2将使事情得到控制，但是Gosh所需的代码量令人难以置信。
我还有其他选择吗？如果我只有上面的2，这是两个邪恶中较小的一个。
由于 约翰
答案 0 :(得分：2)
使用GUID作为主键。它不是100％万无一失（99.和相当多的9％的百分比），并且存在性能损失，但这是最简单的方法，同时保持理智。
答案 1 :(得分：1)
您是否可以在表中包含Office ID并拥有复合主键？如果不是，我可能会使用@tdammers建议使用GUID。
答案 2 :(得分：0)
删除PK约束会在某些时候导致灾难。我投票支持选项2 - 这是更多的工作，但在最后你将拥有一个更强大和可维护的解决方案。这确实意味着办公室数据库将不再与主人相匹配 - 他们也需要更新......
答案 3 :(得分：0)
正如其他人所说，包括Office ID在中心区的所有主要密钥中。数据库将解决主要关键问题，同时保持完整性并允许您按办公室报告。
但请注意，您不需要改变来源＆＃39;数据库结构，如果您可以添加Office ID作为数据传输方法的一部分。只需将办公室ID添加到＆＃39; central＆＃39;中的每个表格即可。数据库并将其包含在主键中（从“源”模式中删除自动增量/标识定义），并在传输时使用办公室ID标记每个记录。这是我们在sql-hub中使用的方法，适用于大多数RDMS（MySQL，MS SQL等）。
重要的是，虽然在“中心”和/或必须更改数据库以添加Office ID，否则您将收到错误且不受欢迎的CROSS JOINS。