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

Чи слід створити структуру бази даних з мінімальною кількістю таблиць?

Чи має бути спроектовано таким чином, що все стоїть на одному місці чи добре, щоб було більше таблиць?

Чи це все одно вплине на що-небудь?

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

EDIT

Я закінчую відповідь так: розмір таблиць НЕ має значення, поки випадок не є винятковим; в цьому випадку денормалізація може допомогти.

Дякую всім за відповіді.

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

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

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

База даних повинна мати рівно стільки таблиць, скільки потрібно. Ні менше, ні більше.

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

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

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

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

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

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

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

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

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

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

Наявність мінімальної кількості таблиць вважає мене дуже своєрідною метою.

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

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

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

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

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

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

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

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

Я думаю, що кількість таблиць має значення і може мати великий вплив на продуктивність, якщо ви вирішили розділити дані, які повинні, для всіх бізнес-намірів і цілей, залишатися разом, на кілька таблиць (тобто, щоб у вас була нормалізована база даних). Зазвичай, коли ви це зробите, ви змушені будете ПРИЄДНАТИ Операції (або еквівалент не-SQL), щоб отримати всі необхідні вам дані, а також для таких великих таблиць, структурованих таким чином, продуктивність швидко знижується.

Я не збираюся вникати в деталі, але думаю, що саме реальний факт, що кількість таблиць може впливати на продуктивність, є однією з причин того, що не було винайдено баз даних noSQL, таких як Cassandra, Mongo та Google BigTable (sic!), і тому вони також заохочують знецінювати дані (і, отже, уникаючи великої кількості таблиць / колекцій тощо).

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

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

Дядько Боб стверджує, що Більш просто.

Дивіться сторінку http://c2.com/cgi/wiki?FearOfAddingTables

"хороший дизайн, як правило, спрощується додаванням таблиць"

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

Складіть таблицю країн з кодом континенту. О, ви не можете, тому що насправді є 8 трансконтинентальних країн. Те саме з валютами. Панама використовує два.

Тоді відповідь ТАК.

Але залежать, яке справжнє значення має "мінімальна" кількість таблиць.

Наприклад (антиприклад).

Якщо у мене є наступні об’єкти

1. користувачів
2. замовники

і обидва ділять однакові штати (поля), і тоді немає обмеження безпеки, це більш підходить для створення однієї таблиці

1. table_persons

а не дві різні таблиці

1. table_users
2. table_customers

мінуси, ніж у table_persons, нам потрібно буде додати нове поле (type_of_person).

Інша помилка (помилка, якщо її насправді не потрібно робити) - це "розділити" таблицю, читати як: розділити одну таблицю на два.

1. table_persons

у двох таблицях

1. table_info_persons
2. table_extra_info_persons

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