应用程序数据同步 - 与旧版一起运行新应用程序

Question

我们正在更换旧系统。两个应用程序一起运行将会有一段时间。用户将能够使用任一系统，而挑战是能够保持他们的数据库彼此同步。

新系统是ASP.NET，遗留的是VB6。两者都在SQL Server数据库上运行。目前还不清楚数据库是否在同一个服务器机房，更不用说同一个国家。

桌子上的两种解决方案到目前为止是：坐每台机器上，并通过其他应用程序调用

1. Web服务。
   • 需要修改本地对象的基类（es？）上的Save方法。这是侵入性的，并且在关闭它时可能会成为问题。

2. 单个窗口服务，用于轮询每个数据库并计算出发生了什么变化，并根据需要转发适应的更新。

   • 需要更改这两个应用程序中的模式以确保它们在所有表上都有LastModified（DateTime），因此我们可以在任何给定的时间间隔执行一次定期SELECT。

这两种解决方案看起来都是合理的。两种解决方案都有优点和缺点。该业务要求在更新一个系统和在另一个系统中看到它之间不超过2秒的延迟（！）。这可能是一个伸展目标，但这是目标。已建议，但拒绝

其他（我愿意重新考虑）是：

• 数据库触发器（blugrh）
• 的BizTalk或其他总线（看起来像一个大锤，是太复杂切换解决方案）
• 修改所有的存储过程（NOOOO。）
• SSIS（不知道有足够的了解这个还）

欣赏你可能有的任何想法。

编辑：模式完全不同。

Answer 1

最终，这是通过web服务解决的。它工作得很好。

Answer 2

2秒，这是一个非常紧凑的时间表，我猜你的Windows应用程序的解决方案可能只是不会削减它，而不是是否有数百个在同一时间或改变任何东西，并且投票时间必须几乎每秒都希望使其在2以内。

数据库是否使用相同的结构？如果是这样，我会考虑实施复制。

编辑

的评论和添加的模式是完全不同的，我不得不说，我真的看到两个操作的集合。

1. 修改应用中的数据存储选项以在两个表中进行插入/更新/删除。优势：即时，无需外部流程共享。缺点：必须修改所有代码，很难禁用等。

2. 正如您所述创建同步应用程序以同步更改的数据。优点：完成传输后可以简单地禁用。缺点：编写起来非常复杂，特别是如果有大量表格。另外，速度并不快，2秒将很难完成

Answer 3

个人而言，我会拒绝用户使用任一系统simulataneously的想法。如果用户1在系统1上更改了记录1，并且用户2在系统2上以不同方式更改了记录1，您将如何解决该问题？

此外，如果你不需要人们使用新系统，他们不会。在大多数组织中，抵制变革的能力非常强大。

我会建议您推出新系统，并要求所有人都使用它，并且每小时将数据发送到旧系统，以防因任何原因需要恢复。

我看不到合理的方法来获得2秒钟的同步。这是一个荒谬的要求，应该毫不含糊地告诉商业方面。

有时你只需要反击，当企业用户想要的东西不合理。

Answer 4

你在这里描述的让我感觉就像在噩梦中！我认为你应该首先向每个人说明，在整个转换过程中，考虑到能够允许用户通过2个不同的数据库通过2个不同的应用程序更新所有数据是不可能的（或者至少非常昂贵） ！我什至不谈论2秒的延迟...

据我所知，基本策略应该是逐步将数据更新权限和可能性从旧版切换到新应用程序。用户将能够从双方看到数据，但只能通过其中一个应用程序进行更新。

（incidentaly，这种方法也将迫使用户逐步切换到新的版本，避免expected and annoying resistance issue already exposed by @HLGEM）

一旦这个规则显然是接受了，然后你可以执行以下步骤。

1. 设置允许从遗留数据库向新数据库传输数据的所有过程。我想你将需要在未来几个月内运行几次...
2. 设置所有程序允许以其他方式传输数据（反向数据传输）
3. 在这里，您应该已经确定了同类的表组一起移动。合并前面的代码的方式，你会得到这些组的每一个“数据传输”过程和“反向传输”。

然后，对于每个这些基团的

通过代码或在数据库级

把你的更新限制运行您“数据传送”程序

组织您的“反向传输”过程作为新数据库中的触发器

我猜你将能够传输的第一种数据将是不包含任何外键的列表秒。

以这种方式工作，你会逐渐从那里您可以

• 读/写遗留应用程序+只读 新的应用程序

到

• 读取的情况下切换 - 仅传统应用程序+读/写 新应用程序。