数据复制vs服务总线与应用程序结构vs ...？

Question

我构建的应用程序需要使用源数据库中的数据。源数据库有几个问题，包括：

• 性能问题
可怕键
• 传统结构，命名约定，等
• 大量的数据，我的应用程序不关心

我想要设置特定于应用程序的SQL Server数据库。新数据库将填充来自源数据库（以及一些其他源系统）的数据子集。数据总是从源数据库单向移动到特定于应用程序的数据库（即 - 数据不会同步回源）。它将具有与源数据库不同的DDL模型。 数据并不需要被同步绝对实时，但是任何超过几分钟的滞后可能造成的问题。 我应该如何将数据从源数据库移动到应用程序数据库中？我应该使用

• 复制
• 编写自定义的SSIS包
• Abstact上级SOA解决方案 像nServiceBus，AppFabric的，等等？
• 一些其他的想法？

优点/缺点每个？

Answer 1

听起来像你对我不需要像NServiceBus消息服务 - 这将涉及修改旧系统发布时数据的变化，这是我希望你不要想进入的事件。因为在你的情况下你的本地存储数据稍微过时是可以接受的，所以SSIS包可以被接受。

但是，如果源数据库是非常大的，这可能是一个问题，因为你会做它每隔几分钟。此外，如果遗留系统的用户已经遇到性能问题，每隔几分钟运行一次SSIS包将无济于事。也许你可以引入源数据的时间戳，以便它只复制新的/修改的数据？

如果源数据是非常大的，表现为严重的问题，那么也许NServiceBus将是一个不错的主意。您也可以考虑建立在MSMQ上的公交或您自己的简单解决方案。但是这将意味着让你对遗留代码感到肮脏。