Pro*_*uye 5 sql-server-2008 sql-server
我在五个不同的地理位置有五个具有相同架构的 SQL Server 数据库。这些位置定期向中央服务器发送备份，我在五个各自的数据库中恢复这些备份。
现在的要求是，这五个数据库的数据必须合并到一个数据库中进行整合。
任何有关解决方案的建议都是非常受欢迎的。
问题有些缺乏细节；例如，了解以下内容会很有帮助：
将数据合并到一个数据库中的原因是什么？如果这样做没有进一步的目标，对我来说就没有意义。也许有更好的方法可以通过更少的中间步骤实现最终目标。
进行备份的源和恢复备份的目标之间是否存在某种边界，从而阻止使用更直接的方法？
源站点之间存在什么样的数据重叠？显然，用户数据会有所不同，但诸如默认/预定义行之类的内容可能很常见（它们是用户可编辑的吗？）。
数据库模式的结构如何？是否定义了足够的代理键和业务键来唯一地标识行，或按业务含义合并行？如果您选择编程/动态方法来合并数据，这一点至关重要。
数据访问策略是什么？是基于存储过程，还是直接表访问，还是通过视图等？
无论如何，根据上述问题的答案，您可以采用以下几种不同的架构。
最明显且可能破坏性最小的方法是向现有环境添加一段代码，将恢复的数据库中的数据合并在一起。
根据数据库中表的数量，您可以简单地编写脚本（对于少量表），或者看看是否有现成的软件可以为您完成此操作（对于大量表） ）。既然你问这个问题，我假设桌子的数量并不小。
实际上，我已经为我们的数据库编写了一个软件，该软件基本上可以实现此目的（我们没有使用现成的，因为我们有自定义要求），该数据库大约有 750 个表，并且需要合并公共数据。我现在告诉你，这不是一件容易的事。如果有自定义要求，我会强烈考虑手动编写传输过程的脚本，即使对于相对大量的表也是如此。这听起来可能需要大量工作，确实如此，但它的创建和维护更简单——复杂性在于大小而不是代码魔法，后者更难以调试和测试。
合并复制。这可以直接从源数据库完成，假设源和目标之间没有任何障碍（见上文）。
这引入了额外的要求、潜在的性能问题以及源数据库的支持复杂性。仅当架构非常干净并且源之间的数据重叠很少时，我才会推荐这样做。
外壳数据库。在目标位置创建一个新的（空）数据库，其中包含模仿源表的视图或使用各个目标数据库的三部分名称UNION或数据的视图。UNION ALL
如果最终计划是创建数据仓库之类的事情，而您最终只是要扫描目标数据库，那么此策略可能会非常有效，因为如果您最终添加更多数据库，它是完全透明的。它还需要很少的额外存储空间。
这些是我能立即想到的一些架构。毫无疑问还有其他人。您最终要做的事情在很大程度上取决于您的具体环境和要求。