系统迁移计划需要帮助

Question

我需要重写旧的ASP.NET web表单VB应用程序到新的ASP.net mvc在c#中。

问题是，大多数用于数据插入检索的旧应用程序逻辑都是用存储过程编写的，随着时间的推移，存储过程变得非常混乱，因为老团队正在添加大量存储过程，这些存储过程都在执行相同的任务，但随着时间的推移，存储过程中包含了一些小的修复，例如FetchById1、FetchById1_fixed等。

我想摆脱这一点，并使用ORM等实体框架，但数据库设计并不是很友好的ORM。数据分散，需要大量的连接来查询数据，这将使EF查询非常慢，特别是因为应用程序大多面向读取。Aprox 50-60人同时插入新闻文章，并且可以同时加载多达10-30k的用户(根据分析现实时间)。

由于主域是围绕新闻文章和文章表的，我的计划是添加一个数据库触发器，它将触发对我们服务器上的一个小服务的http调用，并发出新创建或更新的文章的id信号。服务将包含将数据从旧数据库映射到新数据库所需的所有逻辑。(最初的计划是使用某种消息队列，但我们不想触及旧CMS的遗留代码)。

这样，我计划在我们的遗留系统中实现一切正常工作，但是我们的团队可以开发将连接到一个新数据库的应用程序。

我在正确的轨道上吗？我应该考虑其他的方法吗？

Answer 1

我不喜欢这种方法，因为它似乎没有解决你所说的问题。它解决了另一个问题。只有当您需要支持并发访问时，才需要几乎实时的数据复制，也就是说，在启动新应用程序之前，您不能退出旧的应用程序。

此外，这也是：

服务将包含将数据从旧数据库映射到新数据库所需的所有逻辑。

如果您认为这是正确的，那么您没有理由不能在整个数据库上运行完全相同的逻辑。

事实上，您的迁移可能会遇到问题。如果您做了“大银行”迁移，您的迁移脚本可以生成一个记录失败转换的“附带报告”。在某些情况下，您可能需要手动调整源数据以使转换工作。在这种情况下，自动化过程将无法工作--只有手动转换工作、附带后备报告和迭代改进--才能完成这项工作。

所以

1. 编写最好的迁移脚本
2. 运行它并生成余尘报告
3. 检查报告中的任何模式，并尽可能改进迁移脚本。
4. 检查报告中是否存在一次性问题，并修复源数据。
5. 重复步骤2-5，直到您的余尘报告为空。