Чи є безперервне створення та видалення таблиць ознакою архітектурного недоліку?

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

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

Мені з кожним днем ​​стає все очевидніше, що "спритний" стає синонімом погано продуманих, хаотичних, поспішних і штанів. І жодна з цих речей не сумісна з Agile підходом, як я розумію.

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

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

Зрештою, Agile - це лише слово. Те, що ви робите щодня, визначає, чи будете ви успішними чи ні.

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

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

DBA допоможе, просто переконайтеся, що ви отримали DBA, який розуміє розвиток, а також Agile development. Ваша команда розробників потребує пересилення, а не кидання у в'язницю.

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

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

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

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

У світлі коментарів - як правило, внаслідок цього букет ковбоїв, що виправдовують себе як спритний - бігають криком. Швидкий. І опублікуйте все, що можете, на thedailywtf.com, щоб ми могли насолоджуватися вашим жахом.

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

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

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

Щоб відповісти на ваше запитання, ні, це не нормально в процесі Agile.

Там, де це може здатися сприятливим ставленням, - це цикл проектування / розробки / тестування Agile на короткий ітерацій, а акцент Agile - на легкі рішення, що відповідають відомим вимогам, але добре структуровані, щоб можна було відповідати новим вимогам мінімальна зміна. З огляду на ці дві речі, ви можете сказати, що розробник, не знаючи, що може вийти на лінію, але знаючи його зміну, не повинен впливати на БД способом, який неможливо відмінити, просто вносить необхідні зміни в схему в "найлегшим" можливим способом, і тоді з інтервалом кілька наборів "легких" змін будуть перетворені на щось більш постійне і стабільне.

Сказавши це, я ще не працював із розробником, який підписався на теорію та методологію Agile, а також вважав, що регулярно створювати та видаляти таблиці в схемі необхідно з будь-якої причини. Agile не означає удару по штриху чи болта. Якщо вам надається історія, яка вимагає додавання нового поля даних, що належать до певного запису, ви додаєте поле до таблиці. Якщо ця зміна щось порушує, ви з'ясовуєте, чому, і вносите інші зміни, можливо, це можливо (я можу придумати дуже мало речей, які б зламалися, додавши стовпець до запиту БД; якщо він перерветься при такому зміні ви мають більші проблеми). Рефакторинг, як правило, обмежується кодом; Зміна схеми, як правило, є більш задіяним процесом, ніж зміна коду, і тому, коли відбуваються зміни схеми, вони зазвичай робляться більш уважно, і хоча б деяку увагу приділено знанням майбутнього напряму проекту. Необхідність переструктурувати частину або всю базу даних вказує на принциповий збій дизайну; те, що бути Agile, не означає, що не існує "загального плану" основних архітектурних та дизайнерських правил, який слід дотримуватися, органічно будуючи програму та структуру даних.

Зараз у Agile є випадки, коли те, що ви зараз «знаєте», буде суперечити тому, про що ви дізнаєтесь пізніше. Скажімо, у вас є вимога, щоб ваша система мала адресу для кожної людини. Оскільки це співвідношення 1: 1 і дані будуть потрібні у більшості випадків, ви просто додаєте поля Адреса до таблиці Особи. Через тиждень ви отримуєте вимогу, що особа може мати більше однієї адреси. Тепер це відношення 1: N, і щоб правильно їх моделювати, потрібно скасувати попередні зміни, розділивши поля на нову таблицю адрес. Це не буденно, особливо серед старших розробників. Досвідчений розробник побачить, що у Особи є адреса, розгляне їх як концептуально окремі, і створить таблицю Person та таблицю Адреса, пов'язуючи Person з Address з FK посиланням на AddressID. Таку схему, як ця, легше змінити, якщо зміниться характер відносин; не створюючи і не видаляючи цілих "широких" таблиць даних, відносини між особою та адресою можна досить легко змінити від 1: 1 до 1: N до N: N.

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

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

Навіть при спритності для великої системи, як правило, все ще є хтось / команда, що відповідає за схему.

Якщо вони часто вносять такі зміни - зокрема, викидання таблиць і стовпців у реальні програми - це здається ознакою недосвідченості. Це не має нічого спільного з будь-яким процесом, який вони вимагають дотримуватися. "Agile" - це не привід не сідати і думати про дані, які потрібно зберігати, і про те, як вони пов’язані, перш ніж почати розбивати код. Якщо вони виявляють, що вони змінюють більше 10-20% від початкової структури, для мене це показник, вони або не продумують справи, або не мають багато досвіду аналізу вимог та проектування баз даних, і тому вони просто отримують занадто багато чого неправильно на початку.

Хоча це звучить, як ваша команда справді просто ковбойське кодування, насправді не повинно бути нічого поганого з кодом рефакторингу АБО баз даних. Це не втрачена робота - це пристосування до нещодавно вивченої реальності.

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

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

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

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