管理将重大数据库更改迁移到同一应用程序旧版本共享的数据库
我的目标之一是能够部署与旧版本并行运行的新版本 Web 应用程序。 问题是所有东西都共享一个数据库。 新版本中的数据库往往会对数据库表进行重大重构。 我希望随着时间的推移向用户推出应用程序的新版本，并能够在需要时将它们切换回旧版本。
奥伦有一个很好的 post 设置了该问题，但最后的结果是：
“在部署到生产方面，我们仍处于困境中。影响整个系统的更改，即破坏数据库的更改，我将在下一部分中讨论，恐怕这个有点失控了。”
后续帖子从未出现;-)。 您将如何管理将破坏性数据库更改迁移到由同一应用程序的旧版本共享的数据库。 您将如何保持数据同步？
One of my goals is to be able to deploy a new version of a web application that runs side by side the old version. The catch is that everything shares a database. A database that in the new version tends to include significant refactoring to database tables. I would like to be rollout the new version of the application to users over time and to be able to switch them back to the old version if I need to.
Oren had a good post setting up the issue, but it ended with:
"We are still in somewhat muddy water with regards to deploying to production with regards to changes that affects the entire system, to wit, breaking database changes. I am going to discuss that in the next installment, this one got just a tad out of hand, I am afraid."
The follow-on post never came ;-). How would you go about managing the migration of breaking database changes to a database shared by old version of the same application. How would you keep the data synced up?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
阅读 Scott Ambler 的书“重构数据库”； 对此持保留态度，但其中有很多好主意。
可用解决方案的详细信息取决于您使用的 DBMS。 但是，您可以执行以下操作：
在某些情况下，您不需要新表 - 您可能只需要触发器。
Read Scott Ambler's book "Refactoring Databases"; take with a pinch of salt, but there are quite a lot of good ideas in there.
The details of the solutions available depend on the DBMS you use. However, you can do things like:
In some circumstances, you don't need a new table - you may just need triggers.
如果必须维护旧版本，则更改根本不能破坏。 这在部署新版本的网络应用程序时也很有帮助 - 如果您需要回滚，如果您可以保持数据库原样，它确实会有所帮助。
显然，这会带来严重的架构障碍，并且您几乎肯定会最终得到一个显示其血统的数据库，可以这么说 - 但根据我的经验，部署的好处通常值得头痛。
如果您对所涉及的每个旧版本都有可靠的集成测试集合，这会有所帮助。 您应该能够针对仍被视为“可能存在”的每个版本的迁移测试数据库运行它们 - 在某些情况下很可能是“曾经的每个版本”。 如果您能够相当严格地控制部署，您可能会只兼容三个或四个版本 - 在这种情况下，如果确实需要，您可以计划逐步淘汰过时的表/列等。 请记住这种规划相对于所产生的好处的复杂性。
If the old version has to be maintained, the changes simply can't be breaking. That also helps when deploying a new version of a web app - if you need to roll back, it really helps if you can leave the database as it is.
Obviously this comes with significant architectural handicaps, and you will almost certainly end up with a database which shows its lineage, so to speak - but the deployment benefits are usually worth the headaches, in my experience.
It helps if you have a solid collection of integration tests for each old version involved . You should be able to run them against your migrated test database for every version which is still deemed to be "possibly live" - which may well be "every version ever" in some cases. If you're able to control deployment reasonably strictly you may get away with only having compatibility for three or four versions - in which case you can plan phasing out obsolete tables/columns etc if there's a real need. Just bear in mind the complexity of such planning against the benefits accrued.
假设您的客户端只有 2 个版本，我只会在新表中保留一份数据副本。
您可以在新表之上的视图后面维护新旧应用程序之间的契约。
使用 before/instead 触发器来处理对实际写入新表的“旧”视图的写入。
您正在维护 2 个版本的代码，并且仍然必须开发旧的应用程序，但这是不可避免的。
这样，就不存在同步问题，实际上您必须处理“旧”和“新”模式之间的复制冲突。
如前所述，超过 2 个版本会变得复杂......
Assuming only 2 versions of your client, I'd only keep one copy of the data in the new tables.
You can maintain the contract between the old and new apps behind views on top of the new tables.
Use before/instead of triggers to handle writes into the "old" views that actually write into the new tables.
You are maintaining 2 versions of code and must still develop your old app but it is unavoidable.
This way, there are no synchronisation issues, effectively you'd have to deal with replication conflicts between "old" and "new" schemas.
More than 2 versions becomes complicated as mentioned...
首先我想说这个问题很难，你可能找不到完整的答案。
最近，我参与了维护旧版业务应用程序，该应用程序可能很快就会发展到新版本。 维护包括解决错误、优化旧代码和新功能，这些功能有时无法轻松适应当前的应用程序架构。 我们的应用程序的主要问题是它的文档记录很差，没有任何更改的痕迹，而且我们基本上是从事该项目的第五个轮换团队（我们对此还很陌生）。
将外部细节（代码、层等）放在一边，我将尝试解释一下我们当前如何管理数据库更改。
目前，我们试图遵循两条规则：
首先，旧代码（sql、存储过程、函数等）按原样工作，并且应该保持原样，除非有必要，否则不要修改太多情况（错误或功能更改），当然，尝试尽可能多地记录它（尤其是以下问题：
“WTF！他为什么这样做而不是那样？”）。
其次，每个新功能的出现都应该使用目前已知的最佳实践，并尽可能少地修改旧的数据库结构。 这将引入一些数据库重构选项，例如在旧结构之上使用可编辑视图、为现有结构引入新的扩展表、规范结构并通过视图提供旧结构等。
此外，我们正在尝试编写尽可能多的单元只要业务分析师并肩工作并记录业务规则，我们就可以进行测试。
数据库重构是一个非常复杂的领域，需要简短的回答。 有很多书可以回答您的所有问题，一本 http://databaserefactoring.com/ 一本一本地指向答案< /a>.
稍后编辑：希望第二条规则也能回答重大更改的处理。
First, I would like to say that this problem is very hard and you might not find a complete answer.
Lately I've been involved in maintaining a legacy line of business application, which might soon evolve to a new version. Maintenance includes solving bugs, optimization of old code and new features, that sometimes cannot fit easily in the current application architecture. The main problem with our application is that it was poorly documented, there is no trace of changes and we are basically the 5th rotation team working on this project (we are fairly new to it).
Leaving the outer details on the side (code, layers, etc), I will try to explain a little how we are currently managing the database changes.
We have at this moment two rules that we are trying to follow:
First, is that old code (sql, stored procs, function, etc) works as is and should be kept as is, without modifying too much unless there is the case (bug or feature change), and of course, try to document it as much as possible (especially the problems like:
"WTF!, why did he do that instead of that?").
Second is that every new feature that comes in should use the best practices known at this moment, and modify the old database structure as little as it can. This would introduce some database refactoring options like using editable views on top of the old structure, introducing new extension tables for already existing ones, normalizing the structure and providing the older structure through views, etc.
Also, we are trying to write as many unit tests as we can provided the business analysts are working side by side and documenting the business rules.
Database refactoring is a very complex field to be answered in a short answer. There are a lot of books that answer all your problems, one http://databaserefactoring.com/ being pointed in one of the answers.
Later Edit: Hopefully the second rule will also answer the handling of breaking changes.