What are the practical advantages of Doctrine Migrations over just running a schema update?
仅仅运行架构更新，Doctrine Migrations有哪些实际优势？
Safety?
安全？
The orm:schema-tool:update command (doctrine:schema:update in Symfony) warns
orm：schema-tool：update命令（doctrine：schema：在Symfony中更新）发出警告
This operation should not be executed in a production environment.
不应在生产环境中执行此操作。
but why is this? Sure, it can delete data but so can a migration.
但为什么会这样呢？当然，它可以删除数据，但迁移也是如此。
Flexibility?
灵活性？
I thought I could tailor my migrations to add stuff like column defaults but this often doesn't work as Doctrine will notice the discrepancy between the schema and the code on the next diff and stomp over your changes.
我认为我可以定制我的迁移以添加列默认值之类的东西，但这通常不起作用，因为Doctrine会注意到架构和下一个差异上的代码之间的差异并且踩踏你的更改。
3 个解决方案
#1
38
When you are using the schema-tool, no history of database modification is kept, and in a production/staging environment this is a big downside.
当您使用模式工具时，不会保留数据库修改的历史记录，并且在生产/暂存环境中，这是一个很大的缺点。
Let's assume you have a complicated database structure in a live project. And in the next changeset you have to alter the database somehow. For example, your users' contact phones need to be stored in a different format, not a VARCHAR, but three SMALLINT columns for country code, area code and the phone number.
假设您在实时项目中有一个复杂的数据库结构。在下一个变更集中，您必须以某种方式更改数据库。例如，您的用户的联系电话需要以不同的格式存储，而不是VARCHAR，而是三个用于国家/地区代码，区号和电话号码的SMALLINT列。
Well, that's not so hard to figure out a query that would fetch the current data, separate it into three values and insert them back. That's when migrations come into play: you can create your new fields, then do the transforms and finally drop the field that was holding the data before.
好吧，找出一个可以获取当前数据的查询并将其分成三个值并将其插回来并不难。当迁移发挥作用时：您可以创建新字段，然后进行转换，最后删除之前保存数据的字段。
And even more! You can even describe the backwards process (the down migration), when you need to undo the changes introduced in your migration. Let's assume that someone somewhere relied heavily on the format of the VARCHAR field, and now that you've changed the structure, his piece of code is not working as expected. So, you run migration:down, and everything gets reverted. In this specific case you'd just bring back the old VARCHAR column and concatenate the values back, and then drop the fields.
甚至更多！当您需要撤消迁移中引入的更改时，您甚至可以描述向后流程（向下迁移）。让我们假设某个地方某人严重依赖于VARCHAR字段的格式，现在你已经改变了结构，他的代码片段没有按预期工作。因此，您运行migration：down，并恢复所有内容。在这种特定情况下，您只需返回旧的VARCHAR列并将值连接回来，然后删除字段。
Doctrine's migration tool basically does most of the work for you. When you diff your schema, it generates all the necessary up's and down's, so only thing you'll have to do is handle the data that could be damaged when the migration is applied.
Doctrine的迁移工具基本上可以为您完成大部分工作。当您对模式进行区分时，它会生成所有必要的向上和向下，因此您只需要处理应用迁移时可能损坏的数据。
Also, migrations are something that gives other developers on your team knowledge on when it's time to update their schemas. With just the schema-tool, your teammates would have to run doctrine:schema:update each and every time they pull, `cause they wouldn't know if the schema has really changed.
此外，迁移可以让团队中的其他开发人员知道何时更新其模式。只使用模式工具，您的队友就必须运行学说：模式：每次拉动时都会更新，因为他们不知道模式是否真的发生了变化。
When using migrations, you always see that there are some updates in the migrations folder, which means you need to update your schema.
使用迁移时，您始终会看到迁移文件夹中有一些更新，这意味着您需要更新架构。
#2
1
I think that you indeed nailed it on Safety. With Migrations you can go back to another state of the table (just like you can do in Git version control). With the schema update command you can only UPDATE the tables. There is no log kept for going back in case of a failure with already saved data in those tables. I don't know exactly, but doesn't a migration also saves the data of the corresponding table that's being updated? That would be essential in my opinion, otherwise there is no big reason to use them.
我认为你确实把它钉在了安全上。使用迁移，您可以返回到表的另一个状态（就像您可以在Git版本控制中一样）。使用schema update命令，您只能更新表。如果这些表中已保存的数据出现故障，则不会保留用于返回的日志。我不确切知道，但迁移是否也会保存正在更新的相应表的数据？这在我看来是必不可少的，否则没有什么大的理由可以使用它们。
So yes, I personally think that the main reason for using migrations in a production environment is safety and maybe a bit of flexibility. Safety would be the winner here I think :)
所以，是的，我个人认为在生产环境中使用迁移的主要原因是安全性和可能的灵活性。我认为安全将成为赢家:)
Hope this helps.
希望这可以帮助。
edit: Here is another answer with references to the Symfony docs: Is it safe to use doctrine2 migrations in production environment with symfony2 and php
编辑：这是对Symfony文档的引用的另一个答案：使用symfony2和php在生产环境中使用doctrine2迁移是否安全
#3
0
You also cant perform large updates with plain doctrine migration. Like try to update index on 30 mln users database. As it will a lot of time while you app will not be accessible.
您也无法使用简单的学说迁移执行大型更新。就像尝试更新30毫升用户数据库的索引一样。因为很多时候你的应用程序将无法访问。
#1
38
When you are using the schema-tool, no history of database modification is kept, and in a production/staging environment this is a big downside.
当您使用模式工具时，不会保留数据库修改的历史记录，并且在生产/暂存环境中，这是一个很大的缺点。
Let's assume you have a complicated database structure in a live project. And in the next changeset you have to alter the database somehow. For example, your users' contact phones need to be stored in a different format, not a VARCHAR, but three SMALLINT columns for country code, area code and the phone number.
假设您在实时项目中有一个复杂的数据库结构。在下一个变更集中，您必须以某种方式更改数据库。例如，您的用户的联系电话需要以不同的格式存储，而不是VARCHAR，而是三个用于国家/地区代码，区号和电话号码的SMALLINT列。
Well, that's not so hard to figure out a query that would fetch the current data, separate it into three values and insert them back. That's when migrations come into play: you can create your new fields, then do the transforms and finally drop the field that was holding the data before.
好吧，找出一个可以获取当前数据的查询并将其分成三个值并将其插回来并不难。当迁移发挥作用时：您可以创建新字段，然后进行转换，最后删除之前保存数据的字段。
And even more! You can even describe the backwards process (the down migration), when you need to undo the changes introduced in your migration. Let's assume that someone somewhere relied heavily on the format of the VARCHAR field, and now that you've changed the structure, his piece of code is not working as expected. So, you run migration:down, and everything gets reverted. In this specific case you'd just bring back the old VARCHAR column and concatenate the values back, and then drop the fields.
甚至更多！当您需要撤消迁移中引入的更改时，您甚至可以描述向后流程（向下迁移）。让我们假设某个地方某人严重依赖于VARCHAR字段的格式，现在你已经改变了结构，他的代码片段没有按预期工作。因此，您运行migration：down，并恢复所有内容。在这种特定情况下，您只需返回旧的VARCHAR列并将值连接回来，然后删除字段。
Doctrine's migration tool basically does most of the work for you. When you diff your schema, it generates all the necessary up's and down's, so only thing you'll have to do is handle the data that could be damaged when the migration is applied.
Doctrine的迁移工具基本上可以为您完成大部分工作。当您对模式进行区分时，它会生成所有必要的向上和向下，因此您只需要处理应用迁移时可能损坏的数据。
Also, migrations are something that gives other developers on your team knowledge on when it's time to update their schemas. With just the schema-tool, your teammates would have to run doctrine:schema:update each and every time they pull, `cause they wouldn't know if the schema has really changed.
此外，迁移可以让团队中的其他开发人员知道何时更新其模式。只使用模式工具，您的队友就必须运行学说：模式：每次拉动时都会更新，因为他们不知道模式是否真的发生了变化。
When using migrations, you always see that there are some updates in the migrations folder, which means you need to update your schema.
使用迁移时，您始终会看到迁移文件夹中有一些更新，这意味着您需要更新架构。
#2
1
I think that you indeed nailed it on Safety. With Migrations you can go back to another state of the table (just like you can do in Git version control). With the schema update command you can only UPDATE the tables. There is no log kept for going back in case of a failure with already saved data in those tables. I don't know exactly, but doesn't a migration also saves the data of the corresponding table that's being updated? That would be essential in my opinion, otherwise there is no big reason to use them.
我认为你确实把它钉在了安全上。使用迁移，您可以返回到表的另一个状态（就像您可以在Git版本控制中一样）。使用schema update命令，您只能更新表。如果这些表中已保存的数据出现故障，则不会保留用于返回的日志。我不确切知道，但迁移是否也会保存正在更新的相应表的数据？这在我看来是必不可少的，否则没有什么大的理由可以使用它们。
So yes, I personally think that the main reason for using migrations in a production environment is safety and maybe a bit of flexibility. Safety would be the winner here I think :)
所以，是的，我个人认为在生产环境中使用迁移的主要原因是安全性和可能的灵活性。我认为安全将成为赢家:)
Hope this helps.
希望这可以帮助。
edit: Here is another answer with references to the Symfony docs: Is it safe to use doctrine2 migrations in production environment with symfony2 and php
编辑：这是对Symfony文档的引用的另一个答案：使用symfony2和php在生产环境中使用doctrine2迁移是否安全
#3
0
You also cant perform large updates with plain doctrine migration. Like try to update index on 30 mln users database. As it will a lot of time while you app will not be accessible.
您也无法使用简单的学说迁移执行大型更新。就像尝试更新30毫升用户数据库的索引一样。因为很多时候你的应用程序将无法访问。