应用程序数据同步 - 新应用程序与旧应用程序同时运行
我们正在更换旧系统。 这两个应用程序将在一段时间内同时运行。 用户将能够使用任一系统，挑战是能够保持他们的数据库彼此同步。
新系统是ASP.NET，旧系统是VB6。 两者都在 SQL Server 数据库上运行。 目前还不清楚这些数据库是否位于同一个服务器机房，更不用说位于同一个国家了。
目前提出的两种解决方案是：
- Web 服务位于每台计算机上并由其他应用程序调用。
- 需要修改本机对象基类上的 Save 方法。 这是侵入性的，并且在关闭时可能会出现问题。
单个 Windows 服务，轮询每个数据库并找出更改的内容并根据需要转发调整后的更新。
- 需要更改两个应用程序中的架构，以确保它们在所有表上都有 LastModified (DateTime)，以便我们可以在任何给定的时间间隔执行定期 SELECT。
两种解决方案看起来都很合理。 两种解决方案都有优点和缺点。 该企业要求更新一个系统和在另一个系统中看到它之间的延迟不超过 2 秒（！）。 这可能是一个延伸目标，但却是一个值得追求的目标。
其他已建议但被拒绝的（我愿意重新考虑）是：
- 数据库触发器（blugrh）
- BizTalk 或其他总线（看起来像大锤，对于切换解决方案来说太复杂）
- 修改所有存储过程（不。）
- SSIS（对此还不够了解）
感谢您的任何想法。
编辑：注意模式完全不同。
We're in the process of replacing a legacy system. There is going to be a period of time with both the applications running in tandem. Users will be able to use either system and the challenge is to be able to keep their databases in sync with each other.
The new system is ASP.NET and the legacy is VB6. Both are running on a SQL Server database. It is unclear at this time if the databases will be in the same server room, let alone the same country.
The two solutions on the table so far are:
- Web services that sit on each machine and is called by the other application.
- Need to modify the Save method on the base class(es?) for the native objects. This is invasive and could be a problem when it comes to switching it off.
A single windows service that polls each database and works out what's changed and forwards adapted updates as appropriate.
- Need to change the schemas in both applications to ensure that they have a LastModified (DateTime) on all tables so we can do a periodic SELECT at any given interval.
Both solutions seem reasonable. Both solutions have pros and cons. The business has asked for no more than a 2 second delay(!) between updating one system and seeing it in the other. That's possibly a stretch target but it's something to aim for.
Others that have been suggested but rejected (I'm willing to reconsider) are:
- Database triggers (blugrh)
- BizTalk or other bus (seems like a sledge hammer and is too complex for a switchover solution)
- Modifying all the stored procedures (noooo.)
- SSIS (don't know enough about this yet)
Appreciate any thoughts you may have.
EDIT: N.B. The schemas are completely different.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
2秒，这是一个非常紧迫的时间线，我猜你的Windows应用程序解决方案可能无法削减它，如果一次有数百个更改或任何东西，并且轮询时间必须几乎每秒才能完成希望能在2内完成。
数据库使用相同的结构吗？ 如果是这样，我会考虑实施复制。
编辑
在评论和添加架构完全不同之后，我不得不说，我确实看到了两组操作。
修改应用程序中的数据存储选项以在两个表中进行插入/更新/删除。 优点：即时，无需共享外部流程。 缺点：必须修改所有代码，难以禁用等。
如您提到的那样创建一个同步应用程序，以同步更改的数据。 优点：传输完成后可以简单地禁用。 缺点：写起来非常复杂，特别是如果有大量表。 另外，没有那么快，2 秒将很难完成
2 seconds, that is a really tight timeline, and I'm guessing that your windows app solution just might not cut it, not if there are hundreds of changes or anything at one time, and the poll time has to be almost every second to hope to make it within 2.
Are the databases using the same structure? If so, I'd look at implementing replication.
Edit
After the comment and addition that the schemas are entirely different, I have to say that really I see two sets of operations.
Modify the data storage options IN the app to make inserts/updates/deletes in both tables. Advantage: Immediate, no external process to share. Disadvantage: have to modify all code, hard to disable etc.
Create a sync application as you mentioned, to sync changed data. Advantage: can simply disable after transfer done. Disadvantage: very complex to write especially if there are a large number of tables. Also, not as fast, 2 seconds is going to be VERY hard to accomplish
就我个人而言，我会拒绝用户同时使用任一系统的想法。 如果用户 1 在系统 1 上更改了记录 1，而用户 2 在系统 2 上以不同的方式更改了记录 1，您将如何解决该问题？
此外，如果你不要求人们使用新系统，他们就不会。 在大多数组织中，变革的阻力都非常强烈。
我建议您部署新系统并要求所有人使用它并每小时向旧系统发送数据，以防您因任何原因需要恢复。
我认为没有合理的方法来获得 2 秒同步。 这是一个荒谬的要求，应该明确地告知业务方。
有时候，当企业用户提出不合理的要求时，你就必须反击。
Personally I would reject the idea of users using either system simulataneously. How are you going to resolve the issue if user 1 changed record 1 on system 1 and user 2 changed record 1 in a different way on system 2?
Further, if you don't require people to use the new system, they won't. Resistance to change is very very strong in most organizations.
I would suggest instead that you rollout the new system and require all to use it and hourly send data to the old system in case you need to revert for any reason.
I see no reasonable way to get a 2 second synch. That is a ridiculous requirement and the business side should be told so in no uncertain terms.
Sometimes you just have to fight back when busines users want something unreasonable.
你在这里所描述的让我感觉就像在噩梦中一样！ 我认为您应该首先开始向每个人表明，在整个转换过程中不可能（或至少非常昂贵）允许用户通过 2 个不同的应用程序使用 2 个不同的数据库更新所有数据！ 我什至不是在谈论 2 秒的延迟......
根据我的说法，基本策略应该是逐步将数据更新权限和可能性从旧版应用程序切换到新应用程序。 用户将能够看到双方的数据，但只能通过其中一个应用程序进行更新。
（顺便说一下，这种方法也会迫使用户逐渐切换到新版本，避免in-tandem-with-the-legacy#272672">@HLGEM 已经暴露了预期且烦人的阻力问题）
一旦明确接受此规则，您就可以实施以下步骤。
然后，对于每个组，
我想您将能够获得第一种数据要传输的列表将不包含任何外键。
情况切换
新应用程序
到
新应用程序。
What you describe here makes me feel like in the middle of a nightmare! I think you should first begin to make clear to everybody that it is impossible (or at least extremely expensive) to think of being able to allow the users to update all of the data through 2 different application with 2 different databases during the whole transition process! I am not even talking about the 2 seconds delay ...
According to me, the basic strategy should be to gradually switch data update rights and possibilities from the legacy to the new app. Users will be able to see the data from both sides, but will be able to update it only through one of the apps.
(incidentaly, this method will also force the users to switch gradually to the new version, avoiding expected and annoying resistance issue already exposed by @HLGEM)
Once this rule is clearly accepted, you could then implement the following steps.
Then, for each of these groups
I guess the first kind of data you'll be able to transfer will be lists that do not contain any foreign keys.
Working this way, you will gradually switch from a situation where you have
new app
to
new app.
最后通过网络服务解决了这个问题。 效果非常好。
In the end this was solved with a webservice. It worked really well.