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

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

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

Редагувати: Існує стільки відрази до цього, мені цікаво, скільки проектів в кінцевому підсумку не додає функції, яка вимагає кардинальної зміни бази даних або ненормованих підходів, таких як додавання поля DepartmentID2 замість нової таблиці. Потреба в декількох відділах для працівника є загальною проблемою домену. Я просто не помічав багатьох схем баз даних, які всіяні багатьма стосунками.

Про рефакторинг баз даних написана ціла книга. Як і в разі рефакторингу коду, існують стандартні способи зробити рефакторинг баз даних. Єдина відмінність полягає в тому, що, виконуючи рефакторинг коду, вам не доведеться враховувати стан об'єкта / коду, тоді як у базах даних ви повинні враховувати дані, оскільки втрата даних не є корисною для користувачів (або для когось, насправді ).

Детальніше про рефакторинг баз даних ви можете прочитати тут .

Код рефакторингу простий - ви просто змінюєте код і запускаєте регресійні тести.

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

Страшні речі.

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

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

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

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

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

IMHO це не знадобиться, якби у нас була краща мова, ніж SQL, щоб вказати реляційну алгебру. Якби було можливо побудувати SQL запит по частинах за об'єктами, яким не потрібна видимість до кожної таблиці в запиті, цього не сталося. Такі речі, як LINQ (для SQL або Entities), намагаються вирішити це, але це дуже складне рішення і важко оптимізувати (і я був у групах користувачів DBA, де згадується LINQ і кожен раз піднімається колективний стогін). Я мрію про мову бази даних, яка повсюдно підтримується реляційними функціями алгебри першого класу ...

Тим часом, так, ви можете змінити коефіцієнт від 1 до багатьох до багатьох-багатьох, але це може бути багато роботи.

Я зазвичай пояснюю це таким чином PHB - код - це стіни та дах, база даних - це основа.

Переміщення стін і зміна даху можна зробити. Зміна фундаменту навколо потребує великого копання та відновлення стін та даху.

Те, що говорять недосвідчені розробники (та викладачі коледжів), «над інженерією» - це те, що досвідчені розробники називають «майбутніми перевірами». Незважаючи на те, що специфікація говорить, ви знаєте, що, ймовірно, зміниться під час ALM або де виникнуть проблеми з продуктивністю, тому ви хочете почати структуру таблиці правильно.

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

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

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

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

Існує два способи дивитися на розробку програмного забезпечення (і, мабуть, багато іншого) - Тактичний погляд або стратегічний погляд. У кожного є своя перевага та недоліки.

Навіть при модифікаціях програмного забезпечення OO все ще виникає біль, не тільки кодування частина є складною, але процес сприяння зміні виробництва в середовищі скарг (враховуючи сучасний стан технологій) є нереальним для великих систем, які повинні бути працює 24/7.

Я дотримуюся свого принципу, який говорить: " Коли це можливо, розробляйте артефакти спільного програмного забезпечення стратегічно " - Це може звучати так, як це якимось чином суперечить принципу YAGNI, однак, це моя думка. Такий підхід гарантує менше переробляти витрати на складність та ресурси.

У вашому випадку діяльність, необхідна для додавання нової таблиці з'єднання, включатиме: дизайн, затвердження дизайну, зміна схеми, перезапис декількох методів для CRUD для 3-х таблиць (за винятком деяких читань), побудова індексів, створення GUI для CRUD для нової таблиці, щоб дозволити користувачеві вибирати ПК під час створення, оновлення нової таблиці тощо. О, і, до речі, не забувайте про тестування одиниць, тестування приймання користувачів, тестування системи та просування виробництва.

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

Отже, краще це передбачити з самого початку.

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