Хто розробляє бази даних у веб-розробці? [зачинено]

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

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

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

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

З мого досвіду

• Дизайн бази даних - це поєднана робота розробників та DBA.
• Розробники створюють грубі або часто дуже хороші проекти баз даних. Все залежить від досвіду програмістів.
• Часто розробники створюють таблиці в своїй базі даних розробок, і концептуальна модель з неї реверсується.
• Часто концептуальні діаграми ER обговорюються з іншими членами команди, часто клієнтами. На цьому етапі виявляються очевидні концептуальні помилки та, сподіваємось, з'ясовуються та виправляються.
• Робота DBA полягає в тому, щоб переглянути таку конструкцію та налагодити її для виявлення порушень нормальних форм.
• Також DBA застосовує іменування конвенцій таблиць і стовпців
• Також DBA передбачає можливі вузькі місця та намагається зрозуміти, як будуть запитуватися дані, щоб пізніше створити відповідні індекси.
• Цикл змін / перевірки / виправлення між розробником / дизайнером додатків та DBA проходить через декілька ітерацій, поки модель не зріла, щоб створити фізичну модель.
• Зазвичай інструмент проектування баз даних використовується у всіх, але дуже малих базах даних, щоб допомогти цьому процесу.

Нижня лінія:

• Розробники знають бізнес та проблемну сферу краще, ніж DBA, тому вони дуже багато роблять більшість початкових проектів, і, залежно від досвіду розробника, така конструкція може бути дуже близькою до кінцевої.
• Роль DBA здебільшого полягає у забезпеченні NF, іменуванні конвенцій, міркуваннях щодо ефективності, виправлення очевидних помилок і, нарешті, для створення фізичної моделі, а потім певного сценарію для бази даних та для їх запуску для створення бази даних.
• Я б сказав, що це 80% роботи розробника та аналізу вимог та 20% роботи DBA.

ОНОВЛЕННЯ:

Існує 3 види DBA:

• розробники DBA, які знають моделювання даних, є експертами SQL і можуть записувати збережені процедури, як правило, це колишні розробники;
• виробничі DBA, які спеціалізуються на встановленні, налаштування продуктивності, резервне копіювання та відновлення тощо,
• і DBA-учасників, які працювали, роблячи всі ці речі, і як такі можуть зробити більшість (їх дуже мало).

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

Це залежить, для чого використовується база даних.

У багатьох програмах (веб-додатки чи ні) база даних тісно пов'язана з цим додатком, оскільки вона служить стійким сховищем для неї. Тоді база даних концептуально є частиною програми, тому вона розробляється разом (і ви припускаєте, що жодна інша програма не отримала б значного доступу до цієї бази даних або її оновлення). BTW, наполегливість може бути досягнута іншими способами, ніж база даних, наприклад, звичайні текстові файли, двійкові файли (особливо індексовані файли à la GDBM ), сховища git (або інші VCS), каталоги або дерева файлів, нерозроблені дискові розділи, виділене обладнання (наприклад, спалах), віддалені файлові системи, контрольна точкаприйоми. Для баз даних, розроблених для однієї програми та з однією програмою, вам слід подбати про загальні шаблони пошуку та оновлення та створити схему бази даних (та індексацію!) З ними на увазі.

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

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

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

Я зрозумів, що (PROPER) дизайн бази даних - це не маленьке завдання ...

Читайте також про NoSQL , бази даних документів , орієнтованих на , баз даних ключ-значення , управління знаннями , уявлення знань і міркувань , онтології , експертних систем , бізнес - правила наближаються , ERP , CMS . Можливо, подумайте про використання REDIS , MongoDB тощо.