У проєкті знадобилося внести зміни в структуру таблиць, додати кілька полів і індекси. Як програмісти будуть робити це на продакшені?

Повне пояснення

Що це і навіщо

Міграція – процес оновлення схеми бази даних у продакшені, що дозволяє додавати/видаляти таблиці, колонки та індекси без втрати даних.

Ключові принципи

• Транзакційність: більшість СУБД підтримують DDL‑операції в транзакціях, що гарантує атомарність.
• Версійний контроль: кожна міграція має унікальний ідентифікатор, що дозволяє відстежувати стан схеми.
• Rollback: можливість повернутися до попередньої версії за допомогою down‑скрипту.

Як це працює

1. Створення міграції – ORM генерує SQL‑скрипт, що описує зміни.
2. Застосування – команда migrate deploy запускає скрипт у транзакції, оновлюючи схему.
3. Підтримка – після застосування оновлюється таблиця schema_migrations (або аналогічна), що зберігає історію.

Практика й реалізація

• Prisma: prisma migrate dev --create-only → prisma migrate deploy.
• TypeORM: typeorm migration:create -n AddUserEmail → typeorm migration:run.
• SQL‑скрипти: у випадку ручного застосування – ALTER TABLE users ADD COLUMN email VARCHAR(255); CREATE INDEX idx_users_email ON users(email);.

Тестування

• Unit: перевірка, що міграція не руйнує існуючі дані.
• Integration: запуск prisma migrate deploy у тестовому середовищі, перевірка доступності таблиць.

Оптимізація запитів

• Після додавання індексу слід виконати ANALYZE для оновлення статистики.
• Перевірити план виконання (EXPLAIN) перед релізом.

Безпека

• Використовувати ролі з мінімальними правами: лише роль db_migrator має право виконувати DDL.
• Підписувати скрипти під час CI/CD, щоб запобігти несанкціонованим змінам.

Особливості в контексті ORM

• Prisma: підтримує shadow database для тестування міграцій.
• TypeORM: автоматичний synchronize вимикається в продакшені, щоб уникнути небажаних змін.

Типові помилки

1. Невірний порядок – спроба створити індекс на колонку, що ще не існує.
2. Відсутність транзакції – часткові зміни після падіння.
3. Неправильний тип даних – змінює тип колонки, що порушує існуючі запити.
4. Відсутність down – неможливість повернутися.
5. Проблеми з блокуванням – довготривалі DDL‑операції блокують інші транзакції.
6. Неправильні права – роль без ALTER не може застосувати міграцію.
7. Несумісність версій – використання старої схеми в новому коді.
8. Відсутність резервної копії – ризик втрати даних.

Cheatsheet

• prisma migrate deploy – застосувати всі незастосовані міграції.
• typeorm migration:run – застосувати всі незастосовані міграції.
• ALTER TABLE … ADD COLUMN – додати колонку.
• CREATE INDEX … ON … – створити індекс.

Follow‑up питання

1. Як перевірити, що міграція не вплине на продуктивність?
2. Які стратегії rollback використовуються при помилці?
3. Як забезпечити безперервність доступу під час великих DDL‑операцій?