Як ви підходите до розробки баз даних? [зачинено]

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

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

Тож як ви підходите до бази даних з точки зору веб-додатків? З чого ви починаєте і на що дивитесь? Що таке прапори для обережності?

Найкраща книга, яку я коли-небудь купував щодо дизайну баз даних, - це Дизайн баз даних для простого смертного Майкла Ернандеса ISBN: 0-201-69471-9. Amazon Listing Я помітив, що у нього є третє видання.

Посилання на третє видання

Він проведе вас через весь процес (від початку до кінця) проектування бази даних. Я рекомендую почати з цієї книги.

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

У програмуванні у вас є:

• Якщо конструює
• Якщо інше будує
• Робіть поки петлі
• Робіть, поки петлі
• Конструкти справи

З базами даних у вас є:

• Таблиці даних
• Таблиці пошуку
• Відносини один до одного
• Один з багатьох стосунків
• Відносини багато до багатьох
• Первинні ключі
• Іноземні ключі

Чим простіше ви зробити речі кращими. База даних - це не що інше, як місце, де ви вводите дані в отвори. Спочатку визначте, що це за дірочки і які саме речі ви хочете в них.

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

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

Я займаюся як об’єктно-орієнтованим програмуванням, так і (в основному транзакційним, але деяким OLAP) дизайном баз даних, і, за моїх обставин, є багато повторюваних тем (принаймні, з OLTP).

Практика нормалізації 3nf допомагає мені практикувати якийсь варіант принципу єдиної відповідальності. Таблиця повинна представляти поняття у вашій системі - і поняття повинні стосуватися один одного таким чином, щоб вони намагалися наслідувати реальність; Наприклад, якщо я будую систему, де Клієнт може мати 0 або багато заходів, то я створюю таблицю клієнтів та таблицю активності. Таблиця активності має зовнішній ключ до таблиці Клієнта. Коли я будую збережені процедури, я б обов'язково використовував зовнішнє з'єднання для приєднання Клієнта та активності, оскільки бізнес-вимога, що Клієнт може мати 0 заходів.

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

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

Спочатку я розробляю схему бази даних, потім використовую ORM для створення об'єктів з неї. Я таким чином стара школа; Я не довіряю ORM для створення інтелектуальної, ефективної схеми бази даних. Це робота людини і частина майстерності розробки програмного забезпечення.

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

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

Я також думаю, що важливо розглядати структуру бази даних як зміна сутності, а не припускати, що вам потрібно її обернути та запечатати, перш ніж починати щось інше. Вам слід запланувати зміни та розмістити БД у вашій системі версій. З цього приводу є чудовий нарис: Еволюційний дизайн баз даних Мартіна Фаулера та Прамода Садалажа (а також ціла книга Садалажа на цю тему, хоча я цього не читав).

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

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

• написати короткі речення, що фіксують стосунки між сутностями
• намалюйте схему зв’язків сутності, що представляє речення
• створити нормалізовану логічну модель даних з діаграми ER
• зробити матрицю CRUD для додатків та об'єктів
• використовуйте матрицю для перевірки охоплення життєвого циклу кожного суб'єкта
• витягнути підсхеми для кожної програми
• вивчити шляхи навігації через підсхеми для кожної основної / CRUD-операції
• розглянути звіти, які будуть потрібні
• спроектувати фізичну модель даних на основі всього вищезазначеного; денормалізувати, розділити та використовувати зіркові схеми, де це доречно

Щоб успішно створити базу даних, потрібно спочатку розглянути кілька речей:

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

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

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

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

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

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

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

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

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

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

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

Зрештою, якщо модель стане занадто великою, я пересуну її до Visio і попрацюю над шматками назад на дошці.

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

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

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

Наступний крок - оптимізація створеної схеми.

Минуло давно, як я бачив проект, де таблиці даних, де розроблені вперше.

Мало речей, про які явно не сказано іншими співробітниками:

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

• Добре знати системні цілі та вимоги користувачів. Не знаючи вимог, ви не можете спроектувати правильну модель даних.

• Знайте, який код робити в програмах і який код, щоб дозволити БД піклуватися. Це потрібно, щоб правильно встановити нульовий, а не нульовий стовпець тощо. Це також потрібно, щоб ви правильно вказали свій RI.

• Добре визначте свої первинні ключі. Перейдіть на прості клавіші, коли зможете.

• Розглянемо потреби інтеграції з іншими програмами.

• Подумайте про використання універсальних моделей даних та дотримуйтесь галузевих стандартів у називанні та розмірі стовпців даних.

• Подумайте про майбутні потреби (коли відомо і коли це застосовується)

• Перегляньте ваш режим іншими.

• Використовуйте інструмент для моделювання - або інструмент ERD, або інструмент UML.

• Перегляньте та зрозумійте згенерований код DDL. Не сприймайте це як належне.