І. Вступ
В сучасному світі, майже усі застосунки вимагають наявність бази даних, та часто вибір бази даних, його типу та структури даних, буває дуже складним, а наслідки неправильних рішень на цьому етапі можуть суттєво вплинути на якість проекту, оскільки це «фундамент» на якому побудована уся логіка застосунку та «мова» спілкування для розробників.
ІІ. Проблематика створення структури баз даних для вже існуючих продуктів
Які часті проблеми виникають при плануванні структури баз даних та як їх уникнути:
• Недостатнє планування – згідно дослідження компанії Geneca, близько 55% проектів провалюються через те що можна було виправити більш ретельним плануванням та збором вимог. Це справедливо і для баз даних, відсутність чітких вимог, опису даних, планів на майбутній функціонал критично впливає на планування бази даних, оскільки будь яка неточність може в майбутньому спровокувати, або розширення бази даних, не ефективними методами (додаткові таблиці, дублювання даних та інші), або переробку вже існуючої структури, що займає багато часу та є більш складним процесом. Саме тому розробникам варто враховувати можливість майбутніх змін, уникати великої кількості залежностей між таблицями, що робить майбутню модифікацію дуже складною, та може нести випадкові «втрати» даних.
• Ігнорування внутрішньої термінології проекту – часто бувають ситуації, коли люди що працюють над продуктом та розробники мають складнощі у комунікації, оскільки вони спілкуються різними «мовами». Це стається коли розробники вибирають назви для сутностей та таблиць у базі даних у відриві від продукту, зосереджуючись на технічній складовій цих сутностей. Наслідки такого підходу – сповільнення розробки застосунку, оскільки на комунікацію витрачається додатковий час, та не правильна реалізація логіки. Рішенням є використання популярного зараз підходу Domain-Driven Design – у цьому випадку, створюється чітка термінологія проекту та усі назви в проекті (в першу чергу таблиць сутностей) є напряму похідними від цієї термінології, в такому випадку ми уникаємо розбіжностей між менеджментом та розробниками та між назвами в коді, наприклад коли користувача називають User та Client водночас.
• Ігнорування нормалізації – нормалізація бази даних , це ключовий етап планування структури даних, мета якого знайти баланс між розростанням таблиць через кількість різноманітних пов’язаних даних та розростанням бази за рахунок більшої кількості таблиць з меншою кількістю даних. Стандартом індустрії є досягання третьої нормальної форми, однак потрібно не забувати – ці правила не є універсальними під кожен проект, деколи для проекту вигідніше пожертвувати більш чіткою структурою таблиці, додавши «зайві» колонки, однак цим самим суттєво прискорити операції створення, оновлення, видалення та читання.
• Ігнорування призначення даних – часто під час створення структури баз даних, ми забуваємо для чого нам потрібні ці дані, однак це є важливою складовою планування. Деякі дані потрібні для того щоб один раз їх записати, дуже рідко оновлювати чи видаляти, але дуже часто вичитувати. В таких випадках наприклад має сенс використання механізмів які надає сервер бази даних, наприклад Індекси, так вони сильно ускладнюють додавання, оновлення та видалення даних, однак надзвичайно пришвидшують час який витрачається на отримання цих даних. З іншого боку, якщо ці дані постійно оновлюються але рідко зчитуються, або час їх отримання не є суттєвим, тоді індекси тут є не потрібними і варто зосередитись на оптимізації саме цих операцій.
• Використання однотипних процедур для різних даних – усі люди мають звичку полегшувати собі роботу, зменшувати кількість роботи, особливо рутинної, однак не завжди це добре. Якщо ви маєте багато таблиць написання окремих процедур для кожної таблиці може здаватись даремною тратою часу, тому з’являється спокуса – створити типову процедуру, яка буде працювати для усіх таблиць та перевикористовуватись по всьому проекту. Це одноразово зекономить багато часу, це правда, однак цей підхід ігнорує специфіку кожної таблиці, можливо не усі дані потрібно надсилати на сервер, або можливо їх потрібно спочатку форматувати. Також такий підхід є абсолютно не стійким до помилок – уявимо ситуацію коли відбуваються зміни у вимогах, розробник йде міняти цю процедуру, однак допускає незначну на перший погляд помилку, в результаті уся логіка що використовувала таку процедуру перестає працювати, таким чином, одна невеличка зміна, може вплинути на весь проєкт.
• Не використання усіх можливостей обраного сервера бази даних – часто ми використовуємо певні сервери баз даних не замислюючись над їх особливостями, чи точно нам підходить саме цей варіант. Однак це є важливою складовою роботи з базами даних, до прикладу PostgreSQL – він надає доволі унікальну можливість вибирати структуру що буде використовуватись для зберігання ваших даних, зазвичай це дерево і саме його перебудовування спричиняє уповільнення операцій при використанні індексів. Можливо у вашому випадку варто використати іншу структуру, можливо це суттєво покращить швидкість виконання запитів. Про це не варто забувати, кожен рушій баз даних є різним, зі своїми особливостями, тож варто витратити трішки часу вивчаючи які функції є перевагою для вас, а які недоліком.
ІІІ. Висновки
Проаналізувавши тенденції в розробці програмного забезпечення, типові проблеми та помилки можна зрозуміти наскільки важливим та складним є етап планування для успіху проектів. База даних – це основа на якій створюється успішний продукт, без міцного фундаменту, ви ризикуєте опинитись в ситуації коли продукт стає важко розширювати та майже неможливо модифікувати.
ІV. Список використаних джерел
[1] Project Failure Statistics: Market Report & Data – https://gitnux.org/project-failure-statistics/
[2] Borys Kushch. Що таке Domain-Driven Design та на якому етапі варто його впроваджувати в продукт – https://dou.ua/forums/topic/39874/
[3] Нормалізація баз даних – https:/uk.wikipedia.org/wiki/Нормалізація_баз_даних
[4] Fernando Martinez. Database Design Bad Practices: Are You Making These Mistakes? – https://www.toptal.com/database/database-design-bad-practices
[5] Large Database Architecture And Design: Mistakes And Solutions – https://www.ierek.com/news/large-database-architecture-design-mistakes-solutions/
|
Голосування 
Ця робота ліцензується відповідно до Creative Commons Attribution 4.0 International License
Знайшли помилку? Виділіть помилковий текст мишкою і натисніть Ctrl + Enter