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

时间:2008-11-07 15:55:38

标签: .net database synchronization legacy

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

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

到目前为止,桌面上的两个解决方案是:

  1. 位于每台计算机上并由其他应用程序调用的Web服务。
    • 需要修改本地对象的基类(es?)上的Save方法。这是侵入性的,在关闭它时可能会成为一个问题。
  2. 一个单一的Windows服务,可以轮询每个数据库并找出已更改的内容并根据需要转发适应的更新。

    • 需要更改两个应用程序中的模式以确保它们在所有表上都具有LastModified(DateTime),因此我们可以在任何给定的时间间隔内执行定期SELECT。
  3. 两种解决方案似乎都合理。两种解决方案都有利有弊。该业务要求在更新一个系统和在另一个系统中查看它之间不超过2秒的延迟(!)。这可能是一个伸展目标,但这是一个目标。

    其他被建议但被拒绝的人(我愿意重新考虑)是:

    • 数据库触发器(blugrh)
    • BizTalk或其他总线(看起来像一把大锤,对于转换解决方案来说过于复杂)
    • 修改所有存储过程(noooo。)
    • SSIS(对此还不太了解)

    感谢您的任何想法。

    编辑:N.B。模式完全不同。

4 个答案:

答案 0 :(得分:1)

2秒,这是一个非常紧张的时间表,我猜你的Windows应用程序解决方案可能不会削减它,而不是如果一次有数百个更改或任何事情,并且轮询时间必须几乎希望能在2秒内完成任务。

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

修改

在评论和补充说明模式完全不同之后,我不得不说我真的看到了两组操作。

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

  2. 如上所述创建同步应用程序,以同步已更改的数据。优点:转移完成后可以简单地禁用。缺点:写入非常复杂,特别是如果有大量的表。此外,没有那么快,2秒将非常难以完成

答案 1 :(得分:0)

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

此外,如果您不要求人们使用新系统,他们就不会。大多数组织都非常强烈地反对变革。

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

我认为没有合理的方法可以获得2秒同步。这是一个荒谬的要求,应该毫不含糊地告诉商业方面。

有时你只需要在商业用户想要不合理的东西时反击。

答案 2 :(得分:0)

你在这里所描述的让我感觉像是在噩梦中!我认为你应该首先向所有人明确表示,在整个过渡过程中,能够允许用户通过2个不同的应用程序更新所有数据是不可能的(或者至少是非常昂贵的) !我甚至没有谈论2秒的延迟...

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

(因此,此方法也会强制用户逐渐切换到新版本,避免expected and annoying resistance issue already exposed by @HLGEM

一旦明确接受此规则,您就可以执行以下步骤。

  1. 设置允许从旧数据库到新数据库的数据传输的所有过程。我猜你在未来几个月内需要运行几次......
  2. 设置允许以其他方式进行数据传输的所有程序(反向数据传输)
  3. 在这里,您应该已经识别出可以一起移动的同类表组。合并前面的代码,您将为每个组获得“数据传输”过程和“反向传输”过程。
  4. 然后,对于这些群体中的每一个

    1. 通过代码或数据库级别设置更新限制
    2. 运行“数据传输”程序
    3. 将“反向转移”程序组织为新数据库中的触发器
    4. 我想您可以传输的第一类数据将是不包含任何外键的列表。

      以这种方式工作,您将逐渐从具有

      的情况切换
      • 读/写遗留应用+只读     新应用

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

答案 3 :(得分:0)

最后,这是通过网络服务解决的。它运作得非常好。