与仅运行架构更新相比，Doctrine Migrations 有哪些实际优势？
安全吗？
orm:schema-tool:update 命令（Symfony 中的doctrine:schema:update）发出警告
此操作不应在生产环境中执行。
但这是为什么呢？当然，它可以删除数据，但迁移也可以。
灵活性？
我想我可以调整我的迁移以添加诸如列默认值之类的东西，但这通常不起作用，因为 Doctrine 会注意到架构和下一个差异中的代码之间的差异并踩踏你的更改。
【问题讨论】：
标签： symfony doctrine-orm database-schema
我认为你确实把它钉在了安全上。使用迁移，您可以返回到表的另一个状态（就像您可以在 Git 版本控制中所做的那样）。使用 schema update 命令，您只能更新表。如果这些表中已经保存的数据发生故障，则没有保留日志以备不时之需。我不确切知道，但是迁移不是也保存了正在更新的相应表的数据吗？在我看来，这将是必不可少的，否则没有很大的理由使用它们。
所以是的，我个人认为在生产环境中使用迁移的主要原因是安全性，也许还有一点灵活性。我认为安全将是赢家:)
希望这会有所帮助。
编辑：这是引用 Symfony 文档的另一个答案：Is it safe to use doctrine2 migrations in production environment with symfony2 and php
【讨论】：
当您使用schema-tool 时，不会保留数据库修改历史记录，在生产/暂存环境中这是一个很大的缺点。
假设您在实际项目中有一个复杂的数据库结构。在下一个变更集中，您必须以某种方式更改数据库。例如，您的用户的联系电话需要以不同的格式存储，不是VARCHAR，而是三个SMALLINT 列用于国家代码、区号和电话号码。
好吧，找出一个可以获取当前数据、将其分成三个值并将它们插入回来的查询并不难。这就是迁移发挥作用的时候：您可以创建新字段，然后进行转换，最后删除之前保存数据的字段。
还有更多！当您需要撤消迁移中引入的更改时，您甚至可以描述向后的过程（down 迁移）。让我们假设某个地方的某个人严重依赖VARCHAR 字段的格式，现在您已经更改了结构，他的代码没有按预期工作。所以，你运行migration:down，一切都会恢复。在这种特定情况下，您只需恢复旧的 VARCHAR 列并将值连接回来，然后删除字段。
Doctrine 的迁移工具基本上为您完成了大部分工作。当您区分架构时，它会生成所有必需的 up 和 down，因此您只需处理应用迁移时可能损坏的数据。
此外，迁移可以让您团队中的其他开发人员了解何时需要更新他们的架构。仅使用schema-tool，您的队友每次拉动时都必须运行doctrine:schema:update，因为他们不知道架构是否真的发生了变化。
使用迁移时，您总是会看到迁移文件夹中有一些更新，这意味着您需要更新架构。
【讨论】：
您也无法通过简单的学说迁移来执行大型更新。就像尝试更新 3000 万用户数据库上的索引一样。因为您的应用程序将有很多时间无法访问。
【讨论】：