Why are migrations needed?

Question

symfony

If you only add a column to the table, then it’s understandable
, but if you constantly need to keep the table with melons up to date? wouldn't it be easier to keep a sql-dump of that table in git/svn ?

Answer 1

It is necessary to divide the database into parts: structure, service data and operational data. The structure migrates - it includes schema, tables, keys and all that. Service data - for example, table data with some statuses, can migrate, but you need to be careful here (this data is static in normal mode and is necessary for the code to work). And the rest of the data - that is, users there, posts, goods - it's all not migrated . Their integrity lies on other mechanisms - for example, backups.

Answer 2

Why are migrations needed?

If for good, then their real practical application is only to create a table structure, for example, when installing some kind of bundle. Let's say you have a "News" bundle so that you don't have to go into the database with your hands and run it, even if a ready-made SQL migration will help you do it in automatic or semi-automatic mode.

and if you constantly need to keep the table with melons up to date? wouldn't it be easier to keep a sql-dump of that table in git/svn ?

I won’t say anything about SVN (in my opinion, it died out as a class, even Hg / Mercurial is almost gone), but we do it, we store the base dump in the repository, in some cases we even use Git hooks that check versions A DB and at change - rewrite . dump file and add it to the commit.
And the main problem (*exclusively in our practice) is not even so much in the migrations themselves as such, but in the inferiority of their capabilities, in most cases. Not infrequently, migrations cover only a small part of the database's capabilities, usually these are: basic types of fields, foreign keys and indexes. Such things as: triggers, stored procedures/functions, virtual fields, Views, data types specific to a particular database or just "not popular" data types, such as GEOMETRY- very often, not supported in migrations. Just like, for example, I have not yet come across migration mechanisms that could normally create such an elementary type as ENUM in PostgreSQL, not to mention more complex, composite types, etc.
Regarding Symfony, it, like many other frameworks, does not even support such a data type as "ARRAY", or rather, what is called ARRAY in Symfony - this is in fact a string with a serialized array, and not an array in its "pure form", which ( as a data type) is, for example, in the same PostgreSQL. In view of which, it would be surprising to expect something like this from migrations.
Ни в одном серьёзном/крупно проекте, я пока не видел настолько безумного администратора БД, который бы позволил модифицировать "живую" БД с помощью механизма миграций на уровне фреймворка. Только SQL-код, после предварительного анализа.
На основании всего этого, мы для себя сделали вывод, что миграции отлично подходят для автоматизации создания примитивных болванок в БД, например, тех же "новостей", не более того.
P.S. Я знаю, что для БД существуют специализированные механизмы/программы, для контроля БД, включая данные. Детально пока не разбирался, но подобная возможность ("Контроль версий БД") заявлена, например, в программе SQL Manager for PostgreSQL (для Windows).

Answer 3

Миграции вроде с данными не работают. Только с самой архитектурой.

Answer 4

Миграции нужны для разработки. Например вася хочет создать новую таблицу. Он создает миграцию, накатывает ее в свой локальный проект и делает коммит в гит, из которого остальные берут его и накатывают миграции в своих копиях проекта. Миграции это контроль версий БД. Он используется в разработке. Если же проект готовый то пользуются другими стеками, типа думпов