将相同的数据库合并为一个答案

【问题标题】：Merge identical databases into one将相同的数据库合并为一个
【发布时间】：2014-02-24 08:45:12
【问题描述】：

我们有 15 个数据库，包含 75 个表，平均有一百万行。都具有相同的架构但不同的数据。现在，客户要求我们将所有 15 个数据集中到一个数据库中。用户登录过滤的每组数据。

已完成对应用程序的更改以进行过滤。我们现在的任务是将所有数据库合并为一个。

问题是 PK 和 FK 冲突，因为 PK 和 FK 的类型为 int，因此我们将有 15 个 PK id 为 1。

一个想法是使用。 net 和 DBML 将记录作为新记录插入到新数据库中，让 linq 处理 PK 和 FK 并使用代码处理重复数据。

还有什么其他方法可以做到这一点？

【问题讨论】：

数据库是否有共同的数据，所以新记录应该有现有记录的外键？当数据库包含国家、类型等主数据时，这种情况并不少见……
我希望有些数据会很常见。来自 15 个数据库的客户表和订单表需要合并到一个数据库中。我将有 15 条具有相同 ID 的不同客户记录，这些记录需要连同其所有指向订单的 FK 链接一起更改。
您可以简单地引入复合键并使用 1-15 作为第一个组件。但是，如果 pk 是 iden，那么您就会遇到问题，因为我认为您不能在复合材料中使用 iden。需要更多信息。此登录过滤器是否等同于单个数据库？
身份验证由单独的数据库完成，而新的单个数据库将仅存储映射回身份验证数据库的用户名

标签： sql .net database linq database-migration

【解决方案1】：

当记录在所有数据库中都没有唯一的主键时，集成数据库绝非易事。几周前，我构建了一个类似的集成脚本，我决定为此使用实体框架。

首先是好消息。使用 EF 的 DbContext API，插入完整的对象图并让 EF 处理所有新生成的主键和外键非常容易。这如此简单的原因是，当一个对象的状态更改为Added 所有其粘附对象也变为Added 并且EF 计算出正确的插入顺序。这真是太棒了！它让我在几个小时内构建了复制例程的核心，如果我应该在 T-SQL 中完成它，那将需要很多天。后者也更容易出错。

当然，生活并不那么那么容易。现在是坏消息：

这需要大量的机器资源。当然，我为每个复制步骤使用了一个新的上下文实例，但我仍然必须在具有良好处理器和相当数量内部存储器的机器上执行程序。确切的规格并不重要，信息是：用最大的数据库进行测试，看看你需要什么样的野兽。如果内存消耗不能由你支配的任何机器管理，你必须将例程分成更小的块，但这需要更多的编程。
更改为Added 的对象图必须是发散的。我的意思是应该只有从根开始的1-n 关联。原因是，EF 真的会将所有对象标记为Added。因此，如果图中某处有几个分支引用同一个对象（因为存在 n-1 关联），这些“新”对象将成倍增加，因为 EF 不知道它们的身份。例如Company -< Customer -Order >- OrderType：当只有 2 种订单类型时，插入一个有 10 个客户的根公司，每个客户有 10 个订单，将创建 100 个订单类型记录，而不是 2 个。

因此，困难的部分是找到您的类结构尽可能不同的路径。这并不总是可能的。如果是这样，您必须先添加会聚路径的叶子。在示例中：首先插入订单类型。插入新公司时，您首先将现有订单类型加载到上下文中，然后添加公司。现在将新订单链接到现有订单类型。只有当您可以通过自然键匹配对象时才能做到这一点（在本例中：订单类型名称），但通常这是可能的。
您必须注意不要插入主数据的多个副本。假设前面示例中的订单类型在所有数据库中都相同（尽管它们的主键可能不同！）。不应将源数据库中的订单类型重新插入目标数据库。此外，您必须将源数据中的引用修复到目标数据库中的正确记录（同样通过自然键匹配）。

因此，虽然这不是微不足道的，但它是可行的，并且工作在相对较短的时间内完成。我敢肯定，其他替代方案（t-SQL、集成服务、BIDS，如果可行的话）会花费更多时间或者会有更多错误。而这方面的错误问题在于，它们可能会在很久以后才会显现出来。

后来我发现我在 2) 下描述的问题与使用 AsNoTracking 获取源对象有关。看到这个有趣的帖子：Entity Framework 6 - use my getHashCode()。我使用了AsNoTracking，因为它性能更好，并且减少了内存消耗。

【讨论】：