如何在两个数据库之间双向同步表-SQL Server 2008 R2

我们正在运行SQL Server 2008 R2。我们的操作软件运行在这个数据库上，我们将运行两个单独的操作软件实例来访问两个单独的数据库。两个数据库位于同一个SQL Server上。 数据库中200多个表中有26个表的列表需要跨两个单独的数据库进行同步。这些表可以从任一数据库访问，并且必须在两个数据库之间同步insert/update/deletes。同步需要近乎实时地进行，不少于每分钟一次

我知道我可以硬编码触发器，使用MERGE更新表，但这意味着要编写52（26 x 2）个单独的触发器，这些触发器的所有细节都是硬编码的

我已经研究过复制，但这似乎更倾向于一个主表提供一个子表，而不是双向更新

我已经研究了变更跟踪，但并不是所有的表都定义了PK。这是供应商的数据库，不是我的。我知道所有的桌子都应该有PK。我不知道我能定义PKs 在桌子上

我的另一个想法是用同义词替换其中一个表，这样两个系统实际上都在更新同一个表。我对该解决方案的担忧是“破坏”操作系统的可能性

我刚刚开始研究微软同步框架，以及这是否是一种选择

如有任何想法、建议和指导，将不胜感激

谢谢， 戴夫

这是一个场景。可以处理从订阅者到发布者的更新，但在这种情况下，您需要这样做，当订阅者更新回发布者时，这更适合合并冲突

你需要PKs。如果您有自动增量标识字段，那么这些字段将是一个问题。有一些划分id范围的策略，例如为每个数据库中的表版本设置不同的标识种子值

---

如果不能对数据库进行任何更改，这种方法可能无法满足要求。复制是做这类事情的正确方法，但它确实需要一些能力来改变结构。

CriticalFix，我刚刚发现并开始深入研究合并复制。这些表有PK，只是没有定义为PK。我将与供应商交谈，以了解进行这些更改的含义。合并的复制是否可以在接近实时的情况下运行？我只关心性能，因为这是我们的操作系统。记录本身的数量相当低。是的，这应该可以在接近实时（几秒钟）的情况下工作。这就是为什么复制可能是您的最佳选择。复制可能是