Міграція бази даних: відмінності між версіями

Немає опису редагування
== Ризики та переваги ==
Міграція схеми дозволяє виправляти помилки та адаптувати дані до змін вимог. Вона є важливою частиною еволюції програмного забезпечення, особливо в [[Гнучка розробка програмного забезпечення|гнучкій розробці]].
<!--
 
Застосування міграції схеми до бази даних в продакшні - це завжди ризик. Розробницька і тестові бази даних зазвичай менші і охайніші. Дані в них зрозуміліші, і навіть якщо все поламається їх об'єм достатньо малий для того щоб людина могла опрацювати. Бази даних в продакшні зазвичай величезні, старі і повні несподіванок. Несподіванки можуть з'являтись з багатьох причин:
Applying a schema migration to a production database is always a risk. Development and test databases tend to be smaller and cleaner. The data in them is better understood or, if everything else fails, the amount of data is small enough for a human to process. Production databases are usually huge, old and full of surprises. The surprises can come from many sources:
* Пошкоджені дані які були записані старими версіями ПЗ і не були правильно очищені
* Corrupt data that was written by old versions of the software and not cleaned properly
* Неявні залежності в даних про які всі забули
* Implied dependencies in the data which no one knows about anymore
* Люди які вносять зміни в базу напряму без використання призначених для цього інструментів (міграцій)
* People directly changing the database without using the designated tools
* Помилки в інструментах міграції схеми
* Bugs in the schema migration tools
* Помилки в припущеннях щодо того як дані повинні мігрувати
* Mistakes in assumptions how data should be migrated
For these reasons, the migration process needs a high level of discipline, thorough testing and a sound backup strategy.
 
З цих причин міграції потребують багато дисципліни, ретельного тестування та здорову систему [[Резервне копіювання|резервного копіювання]].
== Schema migration in agile software development ==
 
== Міграція схеми в гнучкій розробці ==
<!--
When developing [[Застосунок|software applications]] backed by a database, developers typically develop the application [[Початковий код|source code]] in tandem with an evolving database schema. The code typically has rigid expectations of what columns, tables and constraints are present in the database schema whenever it needs to interact with one, so only the version of database schema against which the code was developed is considered fully compatible with that version of source code.
 
=== Advantages ===
Developers no longer need to remove the entire test database in order to create a new test database from scratch (e.g. using schema creation scripts from DDL generation tools). Further, if generation of test data costs a lot of time, developers can avoid regenerating test data for small, non-destructive changes to the schema.
-->
 
== Інструменти ==
38 180

редагувань