mysql - скільки стовпців занадто багато?

111

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

У який момент, якщо вони є, вважається занадто багато стовпців?

sql mysql

— Бред
джерело

6

Нам не потрібно постійно використовувати SELECT *. У нас завжди є можливість вибрати лише потрібні стовпці для даної ситуації.

— APC

3

70 стовпчиків ?! Скільки з них не можуть бути нульовими?

— OMG Ponies

1

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

— Годеке

2

@KM. це має бути жарт? Я новачок у MySQL і не можу його отримати, ти мав на увазі ПРИЄДНАЙТЕ хорошу річ чи щось намагатися уникати?

— Елія Ілляшенко

2

Оскільки приєднання є основною складовою SQL, приєднання заради ради приєднання, ймовірно, погіршить продуктивність та ремонтопридатність у будь-якому додатку, який у вас є.

— jeteon

142

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

Те, що вам не потрібно, щоб кожен стовпець повертався за кожним запитом, є цілком нормальним; тому оператор SELECT дозволяє чітко називати потрібні стовпці.

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

— ChssPly76
джерело

29

@KM - ось чому я сказав "атрибути, що належать одній сутності в доменній моделі". Висока кількість стовпців таблиці НЕ робить його денормалізованим; це те, що вказані стовпці представляють це важливо. Крім того, хоча нормалізація, безумовно, хороша річ, це НЕ вирішення всіх життєвих проблем. Хитромудрий питання - чи вважаєте ви, що кількість голосів поруч із питанням / відповіддю ТА обчислюється як select count(*) from votesкожен раз, чи вважаєте ви, що, можливо, він денормалізований? Це робить базу даних SO поганою і Джеффа Етвуда божевільним?

— ChssPly76

@ ChssPly76, це реляційна база даних, а не об'єктна модель. є таблиці, рядки та стовпці, працюйте в рамках цього обмеження, якщо ви хочете максимальної продуктивності, імітуйте свої об’єкти для зручності заради продуктивності. Тож чи слід зберігати кожну інформацію про людину в одному рядку? ні, розбийте їх і згрупуйте їх у різні таблиці (використовуючи мій приклад форми мого попереднього коментаря): "Особа", "Діяльність" "HealthRecords". Збереження SUM з міркувань продуктивності - зовсім інша проблема, ніж зберігання всіх даних у 70 стовпцях, щоб уникнути приєднання.

— КМ.

20

Чи повинен "numberOfTeethPulled" бути частиною запису Person? Ні, це, мабуть, не повинно зберігатися взагалі - ви отримаєте цю інформацію від "ToothExtractionRecord", якщо ваша модель домену вимагає такого рівня деталізації. Але це ВАШ (і, смію сказати, досить надуманий) приклад - це не має нічого спільного з моїм моментом: велика кількість стовпців у таблиці НЕ означає, що таблиця денормалізована. Подумайте про договори на нерухомість / замовлення на купівлю / інші фінансові документи, щоб назвати лише кілька прикладів. Чи можна їх далі розділити на кілька таблиць? Так. Будь-яка причина для цього? Не зовсім.

— ChssPly76

1

+1, це було весело. Якщо ви створюєте іншу таблицю, і це просто стосунки 1: 1, ви, ймовірно, просто повинні включити її до основної таблиці. Це не буде економити місце, воно не буде виконувати настільки краще, якщо ви не вимагаєте, щоб дані проти цих даних взагалі не знаходилися в таблиці. Єдина легітимна причина, яка мені зараз спадає на думку, - це те, якщо там є конфіденційна інформація, така як SSN, інформація про кредитну карту тощо ...

— Vandel212

1

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

— пропозиція не може відмовитись

28

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

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

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

— jonstjohn
джерело

5

Чому MySQL потрібно перебудувати всі індекси в таблиці, якщо модифікований лише один?

— Петро Пеллер

Мені було цікаво те саме. Чому MySQL відновлює всі індекси в таблиці? Чи вказане вище твердження правильне?

— травень

13

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

Застосовуйте такі правила до широкої таблиці, і, швидше за все, у вас буде набагато менше стовпців.

Немає повторюваних елементів або груп елементів
Ніяких часткових залежностей від з'єднаного ключа
Ніяких залежностей від не ключових атрибутів

Ось посилання, яке допоможе вам допомогти.

— JohnFx
джерело

17

It is pretty hard to get that many columns if you are normalizing your database.Не так важко, як здається.

— Петро Пеллер

5

Однозначно не так складно. Люди, здається, не розуміють нормальних форм навколо цих тут частин. Ви можете мати 10000 стовпців і ВСІХ нормалізуватись (навіть до найвищої нормальної форми).

— Hejazzman

2

@foljs І саме тут приходить прийнята практика денормалізації. Якщо ви перебуваєте на перехресті, і машина збирається в’їхати в вас, було б дурно чекати, коли світло стане зеленим. Ви повинні вибратися з дороги. Перебуваючи на червоному світлі, технічно це не може бути законно, ви робите те, що, очевидно, слід робити, враховуючи ситуацію = денормалізація

— user3308043

3

Ви втратили мене, коли почали говорити про машини. Поняття не маю, в чому актуальність.

— JohnFx

2

Однак, як ви робите складні запити в цьому сценарії за допомогою однієї таблиці даних, ви не можете, вам доведеться сильно покладатися на мову програмування та різноманітні інші речі, щоб зробити цю роботу! Тож я, можливо, також повернусь до таблиці зі 170 стовпцями, тому що наявність "ПРИЄДНАЙТЕСЬ" запитів та надзвичайно складного програмування, необхідних для роботи окремих таблиць, мені здається марною тратою часу. Я думаю, що я великий фанат принципу KISS.

— Влад Володимир Геркулес

0

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

— Зеешан Ч.
джерело

0

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

— Сьогодні
джерело