{"id":34734,"date":"2019-10-31T22:00:06","date_gmt":"2019-10-31T19:00:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sravnenie-i-vybor-sistem-migratsii-dannyh\/"},"modified":"2019-10-31T22:00:06","modified_gmt":"2019-10-31T19:00:06","slug":"sravnenie-i-vybor-sistem-migratsii-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/sravnenie-i-vybor-sistem-migratsii-dannyh","title":{"rendered":"Comparison and selection of data migration systems","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Comparison and selection of data migration systems<\/h2>\n

\n\"Comparison
\n
\nThe data model in the development process is subject to change, and at some point, it may no longer align with the database. Of course, the database can be deleted, and then ORM will create a new version that corresponds to the model, but this procedure will lead to the loss of existing data. Therefore, the migration system's function is to synchronize the schema with the data model in the application due to changes without losing existing data.<\/p>\n

In this article, we would like to examine various tools for managing database migrations. We hope this overview will be useful for developers facing such choices.
\n<\/a><\/noindex><\/p>\n

Task<\/h3>\n

\nOur company is currently actively developing the next generation product \u2013 Docs Security Suite (DSS). The server side is being developed in .Net Core, and Entity Framework Core is used as the DBMS accordingly. We are applying the Code First approach in the application design.<\/p>\n

The domain model of the application is created by several developers simultaneously \u2013 each responsible for their logical part of the system. <\/p>\n

In the previous generation of DSS, the classic Entity Framework Migrations (EF 6) was used as the migration management system. However, some complaints have accumulated regarding it, the main one being that EF lacks a reasonable approach to resolving version conflicts. This fact still bothers us during bug fixing in the framework of support, so it was decided to consider alternative options.<\/p>\n

As a result of discussions, the following requirements for the migration management system were formed:<\/p>\n

    \n
  1. Support for various DBMSs. MS SQL Server, PostgreSQL, and Oracle are mandatory, but potentially other systems may also be used.<\/li>\n
  2. Integration with ORM. Initially, the use of EF Core was assumed; however, at the design stage, we were ready to consider other ORMs as well.<\/li>\n
  3. Auto-generation of migrations. Given the Code First development, we would like to avoid the need to manually write migrations.<\/li>\n
  4. Version conflicts. In a distributed development environment, EF Core may fail due to conflicts during merging. This becomes a significant problem since different parts of the application are created by different developers, requiring extensive time for each.<\/li>\n
  5. Comprehensive documentation and support. Here, we believe, further explanations are unnecessary.<\/li>\n
  6. Free of charge. This criterion is conditional, as we are also ready to consider not very expensive systems or expensive ones that excel in convenience.<\/li>\n<\/ol>\n

    \nAs a result of a brief investigation, the following options were identified and deemed desirable for consideration:<\/p>\n

      \n
    1. EF Core Migrations<\/li>\n
    2. DBup<\/li>\n
    3. RoundhousE<\/li>\n
    4. ThinkingHome.Migrator<\/li>\n
    5. Fluent Migrator <\/li>\n<\/ol>\n

      <\/p>\n

      Now, a bit more detail<\/h3>\n

      \n\"Comparison
      \n      EntityFramework Core Migrations<\/a><\/noindex><\/b><\/p>\n

      Naturally, this was the first and primary option to choose. A native tool that works out of the box without any extra hassle. A large amount of documentation, both official and unofficial, simplicity, etc. However, the issues raised regarding traditional EF are just as relevant for EF Core. <\/p>\n

      Thus, the advantages of EF Core include:<\/p>\n