MySQL: кілька таблиць або одна таблиця з багатьма стовпцями?

Тож це більше питання дизайну.

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

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

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

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

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

Який звичайний спосіб це зробити?

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

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

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

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

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

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

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

Я маю хороший приклад. Занадто нормалізована база даних із таким набором відносин:

people -> rel_p2staff -> staff

і

people -> rel_p2prosp -> prospects

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

Така конструкція застосовується для всієї бази даних.

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

У минулому році було використано індексацію та всі низько висячі фрукти, усі запити оптимізовані до досконалості. Це кінець дороги для конкретного нормалізованого дизайну та управління тепер затвердили оновлену програму, яка від цього залежить, а також реструктуризацію бази даних протягом 6 місяців. $$$$ Ой.

Рішенням буде мати пряме відношення до people -> staffтаpeople -> prospect

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

Отже, якщо ви перебуваєте в цій ситуації, вам не доведеться обов'язково вирішувати між однією великою таблицею з багатьма стовпцями та розділяти її, але ви можете об'єднати стовпці в об'єкти JSON, щоб зменшити її, наприклад, замість того, щоб адреса була 5 стовпцями, вона може просто бути одним. Ви також можете зробити запит і на цьому об’єкті.

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

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

Мінуси проектувати складніше, запити стають трохи складнішими

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

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

Загальноприйнятим способом цього буде використання різних таблиць, як у схемі зірки чи схемі сніжинки. Але я хотів би базувати цю стратегію в два рази. Я вірю в теорію про те, що дані повинні існувати лише в одному місці, і для схеми, про яку я згадував, добре працювали б. Однак я також вважаю, що для двигунів звітності та BI-пакетів стовпчастий підхід був би дуже корисним, оскільки він більше підтримує потреби в звітності. Стовпчасті підходи, як і ті, що мають infobright.org, мають величезні підвищення продуктивності та стиснення, що робить використання обох підходів неймовірно корисними. Багато компаній починають розуміти, що лише одна архітектура баз даних в організації не підтримує повний спектр їх потреб. Багато компаній реалізують як концепцію наявності декількох архітектурних баз даних.

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