Чи слід проектувати базу даних перед тим, як записати код програми?

Який найпростіший та найефективніший спосіб розробити базу даних? З моєї точки зору, існує кілька варіантів дизайну магазину даних програми:

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

З вашого досвіду, який ви вважаєте найбільш продуктивним та ефективним методом?

Окрім інших відповідей ...

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

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

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

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

Вам буде важко знайти будь-який сучасний відділ програмного забезпечення, в якому не працює якийсь варіант Agile. Порівняння DBA в порівнянні з цим застрягли в темних століттях, з тими думками, що відповідь @ RobPaller містить все ще загальне місце.

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

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

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

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

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

1. Повзучастість - Ви дозволяєте вводити нові вимоги у невідповідний час.
2. Недостатні бізнес-вимоги - Ваш модельєр даних (або системні аналітики) недостатньо відповідав вимогам бізнес-аналітиків. Це призвело до неповної або неправильної моделі даних для підтримки вимог вашої заявки.

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

Сподіваюся, це допомагає.

Я мав розкіш створити декілька баз даних середньої складності, які використовуються в бізнесі, з різними передніми частинами, включаючи Інтернет, Access та C #.

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

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

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

Я добрий у тому, що роблю. Але є лише один із мене, який робить це в середовищі, яке "не робить розвитку".

Все, що сказано, я все краще розумію правила ведення бізнесу. І я бачу такий собі третій варіант:

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

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

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

На мою думку, це величезна виграш.

Для більшості цілей я б вибрав варіант 2: будувати базу даних паралельно з іншими компонентами. По можливості, використовуйте ітеративний підхід і забезпечуйте функціональність під час створення кожної деталі.

Для цього потрібна певна дисципліна проекту. Застосовуйте нормалізацію жорстко (Boyce-Codd / Fifth Normal Form) щоразу, коли ви змінюєте базу даних, щоб ви підтримували якість і не закінчувались тимчасовою та непослідовною моделлю. Будьте максимально агресивні з правилами ведення бізнесу та супутніми обмеженнями в базі даних. Якщо ви сумніваєтесь, що краще застосувати обмеження рано - ви завжди зможете зняти його пізніше. Будьте уважні до порядку, яким ви реалізуєте архітектурні компоненти, щоб мінімізувати технічну заборгованість. Майте гарний набір рекомендацій щодо проектування баз даних, які купує вся команда розробників.

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

У світі архітектури словосполучення "Форма слідує за функцією" було придумано і пізніше дотримується при будівництві високих будівель. Те саме слід застосувати до інфраструктури та розробки програм.

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

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

Стимулом для використання бази даних повинно бути належне дивитись на неї належним чином: як RDBMS. Так, реляційна система управління базами даних. Коли ви використовуєте RDBMS, вашою метою наперед має бути не лише створення таблиць для зберігання, але й їх пошук. Співвідношення між таблицями повинні моделюватися після того, як дані, які ви хочете бачити, і як вони представлені. Це має базуватися на згуртованості та цілісності даних разом з відомими правилами ведення бізнесу. Ці бізнес-правила можна кодувати у вашому додатку (Perl, Python, Ruby, Java тощо) або в базі даних .

ВИСНОВОК

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

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

Мій типовий робочий процес, якщо він працює один:

1. Визначте, що потрібно робити програмі
2. Подивіться, чи може бути розбита будь-яка з задач на багаторазові компоненти
3. Визначте, яким чином кожне завдання потребує взаємодії зі зберіганням даних - які питання вони задаватимуть даним, як часто вони пишуть тощо.
4. Створіть базу даних так, щоб вона могла відповідати на всі запитання, які нам потрібно задати, і добре виконувати найчастіші завдання.
5. Напишіть заявку.

Оскільки я часто працюю в складі команди, і ми географічно розсіяні (і по часових поясах), ми, як правило, проводимо початкову зустріч із початковим початком:

1. Визначте, що потрібно робити програмі.
2. Визначте, де хороші моменти розбити додаток на автономні компоненти
3. Визначте, яким чином кожен компонент потребує взаємодії з іншими.
4. Домовтеся про API для кожної з взаємодій.

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

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

Чому? Незалежно від того, якою методологією / мовою / набором інструментів я користуюся, якщо всі відповідні дані добре розроблені та зберігаються в БД, я можу їх отримати. Незалежно від того, чи є це у C # / Delphi / FORTRAN / COBOL / Assembly / VBA або Crystal Reports; OO, розроблений або подія / дані / незалежно від цього; спритний або водоспад. Якщо дані є, я можу отримати їх, якщо використовувані інструменти можуть підключитися до бази даних. Я можу створити звіти про продажі, якщо зможу ВИБІРАТИ замовлення на прибуток кварталу - навіть якщо мені доведеться писати його байт-байтом на зборах.

Якщо відповідних даних немає або навіть якщо вони є, але (не) структуровані таким чином, я не можу отримати потрібну інформацію - як її кодувати?

Як зазвичай, це залежить;)

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

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