== Ризики та переваги ==
Міграція схеми дозволяє виправляти помилки та адаптувати дані до змін вимог. Вона є важливою частиною еволюції програмного забезпечення, особливо в [[Гнучка розробка програмного забезпечення|гнучкій розробці]].
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.
== Інструменти ==