Реляційні бази даних та ітеративна розробка

У багатьох підходах до розробки програмного забезпечення, таких як гнучкі методології, дизайн, керований доменом та об'єктно-орієнтований аналіз та дизайн, нам пропонується застосувати один ітеративний підхід до розробки.

Таким чином, ми не повинні робити нашу доменну модель правильно в перший раз, коли ми починаємо працювати над проектом. Натомість, з часом ми перетворюємо модель, оскільки з часом ми глибше розуміємо проблемну область.

Крім того, навіть якщо ми намагатимемося домогтися ідеальної моделі, що, як я вже переконаний, дуже важко, вимоги можуть змінитися. Таким чином , після того , як програмне забезпечення було розгорнуто на виробництво, кінцеві користувачі могли помітити , що певну вимогу не було повністю, або ще гірше, деякі вимоги НЕ було.

Сенс у тому, що нам може знадобитися змінити модель після розгортання програмного забезпечення. Якщо це трапилося, у нас є проблема: у виробничій базі даних є важливі дані користувачів, які вже встановлені у форматі для старої моделі .

Оновлення коду може бути важким завданням, якщо код не розроблений належним чином і якщо система велика. Але це можна зробити з часом, у нас є такі інструменти, як Git, які допомагають нам це робити, не пошкоджуючи готову до виробництва версію.

З іншого боку, якщо модель змінюється, якщо властивості класів зникають чи що завгодно, база даних також повинна змінюватися. Але у нас є проблема: там уже є дані, які неможливо втратити, що вже сформовано для старої моделі.

Схоже, що тут реляційна база даних є бар'єром, який заважає нам робити ітераційну розробку і навіть оновлювати програмне забезпечення, коли цього вимагають кінцеві користувачі.

Я вже використовував один підхід для кодування спеціального класу, який відображає старі таблиці баз даних на нові. Тож ці класи вибирають дані у старому форматі, перетворюють їх у формат, використаний новою моделлю, та зберігають у нових таблицях.

Цей підхід, здається, не найкращий. Моє запитання тут: чи існують відомі та рекомендовані підходи для узгодження ітеративного розвитку з реляційними базами даних?

Це не повинні бути спеціальні класи, але так, вам потрібно щось, що займе базу даних у попередньому форматі та перетворить її у поточну.

Вся справа в тому, що вам потрібно розробити процес написання та тестування цих сценаріїв і дисципліну, щоб ніколи не торкатися баз даних тестування та виготовлення вручну, а завжди за сценаріями міграції.

Кожен раз, коли вам потрібно буде змінити базу даних, ви пишете сценарій, який буде виконувати це, будь то в SQL або використовуючи ваш рівень ORM, і здійснюєте його для контролю версій разом із змінами, які потребують нової схеми. Потім у вас є сценарій управління, який буде оновити базу даних, застосовуючи всі сценарії міграції, які ще не застосовувалися в послідовності.

І переконайтеся, що ви коли-небудь змінюєте будь-яке середовище спільної розробки, тестування та контролю якості, застосовуючи сценарії та повертаючись до попередньої версії, якщо вони не працюють, тож ви можете бути впевнені, що вони працюватимуть за призначенням, коли ви їх розблокуєте на виробництві .

Нова установка виконується просто за допомогою застосування всіх сценаріїв. Через деякий час у вас може з’явитися сотні, і ви подумаєте, що це дуже неефективно, але не потрапляйте в пастку, намагаючись оптимізувати його. Установка - це разове заняття, а її надійні козирі роблять її швидкою.

@Doc Браун вже пов’язав Мартіна Фаулера: Еволюційний дизайн баз даних та /programming/334059/agile-development-and-database-changes , і я додав би Алекса Пападімуліса: Зміни бази даних виконано праворуч , що коротше і має кілька прикладів.

Як гідний приклад інструментальної реалізації такого процесу, я пропоную Alembic . Він заснований на основі Python SQLAlchemy , але ви можете використовувати його з іншими мовами та структурами, якщо вони не мають власної підтримки міграції. На сторінці Вікіпедії на схемі міграції перелічено більше таких інструментів .

Як не дивно, це проблема, яка стоїть перед моєю нинішньою командою з розвитку. Питання містить кілька підзапитів, тому вони будуть вирішені самостійно.

Перш за все, чи реляційна база даних занадто сильно обмежує модель даних, що робить зміни дуже важкими?

Звичайно , але не обов'язково з наведених причин. На жаль, універсальність систем управління реляційними базами даних також призводить до їх падіння. RDBMS спочатку був розроблений, щоб запропонувати відносно просту платформу зберігання даних, яка б приймала великі набори даних і зменшувала їх до відносно невеликого розміру. Це було зроблено за рахунок складності в моделі даних та необхідної обчислювальної потужності. Із збільшенням складності бази даних зберігаються процедури, перегляди, функції та тригери, щоб допомогти адміністраторам баз даних вирішувати складність послідовно та масштабовано.

На жаль, модель реляційних баз даних не є об'єктно-орієнтованою і, природно, не відображається на реальних сутностях, як це має бути модель даних. Це призводить нас до необхідності таких інструментів посередників, як об'єктно-реляційні картографи тощо. На жаль, хоча ці засоби очевидно мають місце в сучасному світі розвитку, їх використання є орієнтованим лише на симптом проблеми складності реляційних даних, а не на основну причину, яка є невідповідністю моделі даних реального світу.

Це призводить до другої частини питання, яка насправді була більшою припущенням, але слід розглядати як питання: чи ми повинні вперше зробити нашу доменну модель правильно?

Так, певною мірою. Як зазначалося в питанні, рідко вдається повністю зрозуміти проблему, коли ми починаємо процес проектування. Однак різниця між абсолютно невірною моделлю даних, на відміну від тієї, яку можна змінити, коли ми отримуємо більш широке розуміння домену, - це модель, яка послідовно відображає реальний світ. Це означає, що ми повинні докласти максимум зусиль, щоб створити початкову модель даних, яка відповідає нашому розумінню проблеми з точки зору її реальних сутностей. Якщо ми почнемо нормалізуватися на неправильних об'єктах, модель даних буде помилятися двома способами, і відновлення буде важким.

Багато в чому перехід до рішень бази даних "Без SQL" є результатом проблем невідповідності моделі даних. Використання об'єктно-орієнтованого ніякого підходу SQL не змушує думати більше про відображення між нашими об'єктами в коді та об'єктами в реальному світі, і коли ми стикаємося з невідповідністю, це часто само собою зрозуміло, оскільки це неможливо реалізувати в нашому база даних. Це призводить до кращого загального дизайну.

Це призводить до остаточного питання: чи модель реляційних даних не відповідає гнучкому підходу?

Ні, але більше навичок не потрібно. Тоді як у світі No-SQL тривіально додати поле або перетворити властивість у масив, це зовсім не банально робити це у реляційному світі. Потрібно, як мінімум, того, хто здатний зрозуміти як реляційну модель даних, так і реальну сутність, яку вони представляють. Ця людина - це людина, яка сприятиме оновленню реляційної моделі в міру зміни розуміння моделі реального світу. Срібної кулі для вирішення цієї проблеми немає.

Головне - не переробляти так сильно, щоб ваша модель змінювалась поза всім розпізнаванням. Навіть при ітераційній розробці ви дійсно повинні будувати поверх існуючих речей, а не переробляти їх на частини.

Це дає вам 2 основні варіанти обробляти великі зміни, коли вони приходять: перший - створити рівень DB як API, використовувати збережені процедури, щоб вони могли бути змінені відповідно до клієнта без зміни основної схеми даних.

Інший спосіб - замінити таблиці невеликою міграцією даних. Коли потрібна велика зміна масштабу, ви створюєте нову схему та реалізуєте набір сценаріїв, щоб взяти старі дані та перемістити їх у новий формат. Для цього це витрачає час, тому ви більше покладаєтесь на більш дешеві методи зміни доступу до даних (наприклад, через SP) як перший вибір.

Отже: 1. постарайтеся продумати дизайн заздалегідь, щоб вам не потрібно щось змінювати.

2. Покладайтеся на обгортки або API, тому зміни обмежені або можуть бути приховані всередині ізольованого компонента

3. Знайдіть час для належного оновлення, якщо вам доведеться.

Ці кроки стосуються всього, а не лише баз даних.