生产数据库中的模式迁移？

Question

我已经开始学习Web开发（Flask和Django是具体的），在我看到的任何地方，数据库的主题总是从迁移开始。

根据我对更新数据库的理解，我们应该

1. 运行“生成迁移脚本的内容”以生成迁移脚本，该脚本可以区分当前模型文件和当前数据库。
2. 在本地数据库上测试迁移脚本。
3. 提交迁移脚本，使其到达生产环境，再次运行脚本以更新生产数据库。

然后从这个链接上阅读维基百科上的Schema Migrations Schema Migration我发现了以下文字：

  

模式迁移通常仅在数据保存时使用   数据库不是真实的，也不是有价值的，例如在软件开发中，   开发人员只使用（可能生成）测试   数据。[引证需要]程序化模式迁移几乎从不   出于同样的原因在生产中进行。

它说应该避免生产中的迁移，那么你应该如何更新你的数据库呢？

Answer 1

我不知道维基百科文章的作者从哪里得到了这个想法;根据历史，它已经在第一次修订中，对我来说，这种任意限制没有意义。

将数据库与程序版本一起迁移通常是必需的，这意味着它对于生产数据库是必要的。我在这里没有区分行中的数据和模式，因为这有点任意。从代码的角度来看，数据库是一种编码数据的方式，编码方案直接影响行中数据的模式和编码。

谈论此类迁移的风险（生产数据库有时包含诸如损坏的数据，通过手动运行SQL查询而修改的数据）或复杂性（如添加和删除外键）等风险可能是有意义的。但是我发现许多产品在发布新版本时会迁移数据和模式。

更新：我已经更新了维基百科页面，让我们看看编辑持续多长时间： - ）

Answer 2

我相信作者的意思是自动架构迁移只应在开发阶段，开发或测试环境中完成，因为在大型生产数据库中可能存在某些可用性或性能模式迁移期间的问题。

例如，在高达5.6的MySQL中，没有原生的在线架构更改，因此在ALTER TABLE运行时，您必然会有一个表锁。如果它是一个小桌子，或者是一个带有生成数据的测试环境，那通常不是问题 - 一个小的会快速完成，你可以丢弃一个测试表并重新生成数据 - 但是一个大表在生产环境中，如果不是几天或几周，可能会锁定数小时，导致系统无法用于涉及该表的任何交互。您必须采用其他迁移方法以最短的停机时间执行更改，并且它们不是简单或安全的自动化。

Answer 3

是的，这很荒谬。模式迁移始终对生产数据库进行。随着需求的变化，通常还需要改变底层数据库。 Django和Flask都有执行数据库更新的路径，Django是当前版本中内置的mirgrate命令，而以前版本中是South。 Flask / SQLAlchemy有alembic来处理架构更改。话虽这么说，它仍然是一个痛苦，可能是危险的，所以测试测试测试，并有一个回滚计划。

Answer 4

是否通过生产中的迁移应用自动架构更改，基本上是组织的策略问题。具有较少有价值数据和/或较小数据库的较新组织倾向于使用这些 - 直到它们遇到迁移需要一天或更长时间甚至可能崩溃的情况。如果重要数据丢失，数据库更改的策略通常会变得更加保守，并且不太可能由编写应用程序的开发人员以及经过层层审核后由DBA或DevOps人员编写的更多。恕我直言，这些陈述反映了组织经验和成熟度，而不是绝对的。换句话说，它已经完成，直到它不起作用，然后其他一些过程就会到位。