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

Я був програмістом останні шість років. Протягом своєї кар’єри я працював над багатьма веб-додатками.

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

Але чи ми, як програмісти, повинні створити всю базу даних з нуля, коли нам доведеться створити нову програму, де дані є настільки важливими та мають безладні вимоги зі складною моделлю даних?

Хіба це не в інтересах програми та компанії, щоб це зробити експертом?

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

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

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

І так само, як код, думка про те, що ти змусиш якогось супер-експерта сісти і подумати важко протягом тижня, а потім записати ідеальний дизайн, який ніколи не потрібно буде змінювати, - ілюзія. Дизайн БД може і змінюватись по мірі розробки програми.

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

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

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

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

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

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

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

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

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

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

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

Тут я бачу два питання:

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

Бізнес-логіка

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

• Ви завжди можете замінити одну базу даних на іншу, або навіть можете вирішити використовувати рішення NoSQL для вирішення потенційних проблем продуктивності.

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

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

Зберігаються дані

• Ви повинні знати, як зберігати дані на різних носіях, включаючи рішення SQL та NoSQL.

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

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

Підсумовувати:

• Модель домену - це основа вашої системи, а не база даних.

• Якщо ви працюєте в невеликій компанії над відносно невеликим проектом, то, ймовірно, вам слід створити базу даних самостійно.

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