用于在Web应用程序中更改数据模型的迂腐检查表

让＆＃39; s说你有一个带有一些数据库的Web应用程序。在您的数据库中，您有一个发票模型，您可以在那里存储您为客户收费的东西。

您的结算系统是灵活的，因此您支持建立税收或独家发票，以及免税发票！在此模型中，您将其存储为：

您使用此几年，为您的数据库写一堆实例。你醒来的一天并决定你不再喜欢这个型号！它允许表示无效状态（什么是不征税，但含税发票？）。因此，您决定要用于新数据模型：

您的数据库＆＃39; S数据都在旧的形状！您＆＃39; ll需要将所有数据移到此新数据模型。

你是一个高度可用的Web应用程序！除非你可以避免它，否则你不会做任何停机时间（井，有计划，无论如何）。

您的系统跨越多台机器（高可用性右侧？），因此您必须在部署期间同时处理多个版本的后端代码。

在那里有一个整个步骤列表，你必须要做的事情来推出这种变化。关于＆＃34;双重写作和＃34 ;,34;回填＆＃34;等等，但是当您最终需要做出向后 - 不兼容的变化时，它实际上有很多步骤！

我觉得我知道这个名单，但是每次偶尔我最终错过了一步，当我走出人迹罕至的时候，这里的列表和＃39;列表，在所有迂科中需要每一段时间。

这里的一个重要细节是您需要逐一推出每个版本。您可以在版本3和第4版上拥有系统的某些部分。但如果您在第3版和版本5上的其他系统上有一些系统，则会使用数据稳定性的问题。这使得很多步骤！根据您的数据模型，您可能能够将多个版本保险为一个（特别是当您具有灵活的系统时）。

当然，申请的初始版本正在使用旧模型。这是您的起点，它可能实际上无法准备好开始引入新模型（特别是如果您的应用程序＆lt; - ＆gt; db图层尤其严格）

如果存在新的表示，此版本将能够读取您的数据而不会爆炸。这并不意味着你正在使用任何新的代表！只是你可以处理它。

许多系统在Don＆＃39; t实际上要求这是一个独特的步骤。您可以将新列添加到数据库中，并将现有查询继续工作只是Fiine。但是你需要更加小心的地方。一些例子：

将新值添加到枚举。如果我只拥有Tax_inclusive和Tax_Exclusive，我需要在我开始将数据迁移到此（或具有新行使用它）之前放入No_Tax处理代码。

系统严格验证。当在某些JSON字典中出现新密钥开始时，系统可能会有错误路径，因此您可能需要为此添加准备代码。

对于SQL数据库，通常是关于将新列添加到数据库中。某些数据库可能不需要此步骤，并且某些数据模型更改可能不需要此（例如，如果您只是将新值添加到枚举中，但底层数据被存储为字符串）

此版本的应用程序将开始填写写入数据库的两个表示。您仍然继续从旧的表示中读取（因此v1的写入仍然有意义），并写入旧的表示意味着在V1 - ＆gt; v2部署，v1读取Don＆＃39; t出陈旧。

对于哈比和＃39的任何行为。从你推出的版本2被写入2，你赢了＆＃39; t已经填写了你的数据的新代表（也许是用户只有一段时间登录的用户＆＃39; ）。为了确保准备好读取新的表示，此迁移应该通过所有现有数据并填写新的表示。

部署版本2后，您需要执行此操作，因为如果在迁移期间会发生版本1写入，则回填值实际上将陈旧。并且在开始阅读新表示之前，您需要执行此迁移，以便正确读取旧记录。

你现在填写了新的领域，所以你可以从中读取！但是，您仍然需要写入两个表示。为什么？因为您的申请版本2仍然从旧领域读取！在部署期间，您＆＃39; LL仍然有先前版本的机器，因此您需要至少在部署期间与共存兼容。

有时不需要，但如果您正在删除需要一次的旧领域，则您希望在此时删除这些约束。如果您不执行此操作，则部署一个应用程序版本的应用程序，其中删除了对旧版本的引用，则可能会击中数据库约束失败等。

此时，以前的版本只是为了向后兼容原因编写到旧表示。所以你可以停止写入旧的表示，并且所有读/写路径都刚刚击中新的表示。

此时，您还需要删除对旧表示（特别是模型字段）的引用，以准备最终迁移。 版本4出版后，查询应不再引用旧表示。 你应该是好的，只是为了完全放弃这个东西！ 在您的特定情况下，可能是其中一些可以合并。 我发现这些步骤足以安全地涵盖最多的情景。 虽然真的，最好的是真正了解为什么需要这么多步骤以及系统的特征是否强加不同的约束。 如果您在实践中遇到这种卷展栏的问题或以其他方式认为这项游戏计划缺少一些关键步骤，请给我发电子邮件！ 我非常好奇地覆盖所有基地。