将来自多个远程SQL数据库的数据合并到一个SQL主数据库中

嗯，我确信这个问题之前已经被问过了，但我还没有找到一个可靠的答案。我正在创建一个解决方案，该方案涉及远程办事处通过Web服务将数据上传到一个主数据库。基本上，每个办公室都会有一个每隔1小时左右运行一次的Windows服务，将任何新数据提取到数据集中，通过http连接到服务器，并上传数据集。服务器然后导入数据，一切都很好。理论上它应该起作用。对。将来自多个远程SQL数据库的数据合并到一个SQL主数据库中

并非如此，所以每个办公室都有一个唯一的OfficeID，由服务器提供给它，以便在服务器上保持唯一。起初我以为我会破解它，直到我意识到自动增量PK的问题。你看，所有的远程办公室已经有了现有的数据，所有的表都有自动增量PK和所有相关的约束条件。具有OfficeID的根/父表没有问题，因为它已经是唯一的，问题在于外键，因为当它们到达服务器时，它们将具有NewID，因此与子项的关系将丢失。

目前我只有2个解决方案。

删除服务器数据库上的所有自动增量和唯一PK约束，并使用OfficeID过滤掉重复的外键。或...
导入数据集时，使用像Scope_Identity等东西来跟踪每一行及其关联的父级，以便每个子行都与正确的父行相关联。

选项1看起来更容易实现，因为它对我来说工作量较少，但是我不知道sql的性能以及数据完整性将成为问题，因为约束无法执行。选项2将保持检查，但需要的代码量是令人难以置信的。

有没有其他的选择我不考虑？如果我只有2个以上，这是两个邪恶中较小的一个。

感谢约翰

来源

2010-09-07 John K.

使用GUID作为主键。这不是100％万无一失（99.和相当大数量的9％），并且有性能损失，但这是在保持理智的同时最简单的方法。

来源

2010-09-07 10:48:36 tdammers

我已经在每个表中使用GUID进行更新/修改，因为我知道现在有办法可以在所有数据库中复制GUID。这可能是我将要使用的路线。在服务器上，我只需要ProductGUID等列，这将确保每个子行都知道它是正确的父类，没有任何疑问。 – 2010-09-08 11:11:46

卸下PK constrainst会在某些时候会导致灾难。我会为选项2投票 - 这是更多的工作，但是最后你会有一个更强大和更可维护的解决方案。这意味着办公室数据库将不再与主人匹配 - 他们也需要更新...

来源

2010-09-07 10:46:08 Paddy

我必须删除它们，我越想越多，我意识到我别无选择。如果你有多个级别的子行深度，跟踪新行等将成为一场噩梦。使用Guids是我将要采用的路线，不会在服务器上重复，因此他们可以按原样进入。 – 2010-09-08 11:19:45

您是否可以在表中包含Office标识并具有复合主键？如果没有，我可能会使用@tdammers建议使用GUID。

来源

2010-09-07 14:23:11

我实际上使用了两者。所有表都具有OfficeID，并且与退出（以前的自动编号PK）组合，现在形成一个组合键。除了GUID之外，我还使用它来保持所有内容的整洁。我保留旧的PK列的原因是服务器数据库已经有报告，希望数据库保持不变，只有所有报告现在将按办公室分组。 – 2010-09-08 11:14:02

正如其他人所说，包括“中央”数据库中所有主键中的Office ID将解决主要关键问题，同时保持完整性，并允许您通过办公室进行报告。

但是请注意，如果您可以添加Office ID作为数据传输方法的一部分，则不需要更改“源”数据库结构。只需将办公室ID添加到“中央”数据库中的每个表中，并将其包含在主键中（从“源”模式中删除自动增量/标识定义），并在传输时使用办公室ID标记每个记录。这是我们在sql-hub中使用的方法，适用于大多数RDMS（MySQL，MS SQL等）。

重要的是，虽然在'中央'数据库上进行的任何连接等都必须更改以添加Office ID，否则您将得到错误和不需要的CROSS JOINS。

来源

2015-06-10 11:02:07

将来自多个远程SQL数据库的数据合并到一个SQL主数据库中

回答

相关问题