1

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

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

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

  1. 位于每台机器上并由其他应用程序调用的 Web 服务。
    • 需要修改本机对象的基类上的 Save 方法。这是侵入性的,并且在关闭它时可能是一个问题。
  2. 一个单一的 Windows 服务,它轮询每个数据库并计算出发生了什么变化并在适当的时候转发适应的更新。

    • 需要更改两个应用程序中的模式以确保它们在所有表上都有 LastModified (DateTime),以便我们可以在任何给定的时间间隔执行定期 SELECT。

这两种解决方案似乎都是合理的。两种解决方案各有利弊。企业要求在更新一个系统和在另一个系统中看到它之间延迟不超过 2 秒(!)。这可能是一个延伸目标,但它是一个目标。

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

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

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

编辑:注意架构完全不同。

4

4 回答 4

1

2 秒,这是一个非常紧迫的时间线,我猜你的 Windows 应用程序解决方案可能不会削减它,如果一次有数百个更改或任何东西,轮询时间几乎必须是每秒希望能在2以内。

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

编辑

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

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

  2. 如您所述,创建一个同步应用程序,以同步更改的数据。优点:传输完成后可以简单地禁用。缺点:写起来非常复杂,尤其是在有大量表的情况下。此外,没有那么快,2 秒将很难完成

于 2008-11-07T16:06:54.467 回答
0

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

此外,如果您不要求人们使用新系统,他们不会。在大多数组织中,对变革的抵制非常强烈。

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

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

有时,当业务用户想要一些不合理的东西时,您只需要反击。

于 2008-11-07T16:46:42.720 回答
0

你在这里描述的让我感觉像是在做噩梦!我认为您首先应该开始向所有人说明,在整个过渡过程中,不可能(或至少极其昂贵)考虑允许用户通过 2 个不同的应用程序和 2 个不同的数据库更新所有数据!我什至不是在谈论 2 秒的延迟......

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

(顺便说一下,这种方法也会迫使用户逐渐切换到新版本,避免@HLGEM已经暴露的预期和烦人的阻力问题

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

  1. 设置所有允许数据从旧数据库传输到新数据库的程序。我猜你需要在接下来的几个月里运行它们几次......
  2. 设置所有允许以其他方式传输数据的程序(反向数据传输)
  3. 在这里,您应该已经确定了可以一起移动的同质表组。合并前面的代码,以便为每个组获得一个“数据传输”过程和一个“反向传输”过程。

然后,对于这些组中的每一个

  1. 通过代码或数据库级别设置更新限制
  2. 运行您的“数据传输”程序
  3. 将您的“反向传输”过程组织为新数据库中的触发器

我猜您可以传输的第一种数据将是不包含任何外键的列表。

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

  • 读/写旧版应用程序 + 只读新应用程序

  • 只读旧版应用程序 + 读/写新应用程序。
于 2008-11-14T10:37:23.610 回答
0

最后,通过网络服务解决了这个问题。它工作得非常好。

于 2009-01-14T22:40:14.270 回答