mysql - сколько столбцов слишком много?

111

Я создаю таблицу, в которой может быть до 70 столбцов. Теперь я подумываю разделить его, так как некоторые данные в столбцах не будут нужны каждый раз при доступе к таблице. Опять же, если я сделаю это, мне придется использовать объединения.

В какой момент считается слишком много столбцов?

sql mysql Брэд
источник
6
Нам не нужно постоянно использовать SELECT *. У нас всегда есть возможность выбрать только те столбцы, которые нам нужны для данной ситуации.
APC,
3
70 столбцов ?! Сколько из них не может быть нулевым?
OMG Ponies,
1
Большой вопрос ... вы нормализуете свои таблицы? 70 - необычная сумма, если только вы не намеренно денормализуете производительность (очень немногие вещи имеют 70 уникальных атрибутов). Если вы выполняете денормализацию ради производительности, я бы согласился с ChssPly76, что вы можете использовать все, что позволит вам база данных.
Годеке,
2
@KM. это должно быть шутка? Я новичок в MySQL и не могу его понять. Вы имели в виду, что JOIN - это хорошо или что-то, чего следует избегать?
Элия ​​Ильяшенко
2
Поскольку объединения являются основной частью SQL, объединение ради объединения, вероятно, ухудшит производительность и ремонтопригодность для любого вашего приложения.
jeteon

Ответы:

142

Считается, что их слишком много, если он превышает максимальный лимит, поддерживаемый базой данных .

Тот факт, что вам не нужно, чтобы каждый столбец возвращался каждым запросом, совершенно нормально; вот почему оператор SELECT позволяет вам явно назвать нужные столбцы.

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

ChssPly76
источник
29
@KM - поэтому я сказал «атрибуты, принадлежащие одному объекту в модели предметной области». Большое количество столбцов в таблице НЕ делает ее денормализованной; важно то, что представляют указанные столбцы. Кроме того, хотя нормализация - это определенно хорошо, это НЕ решение всех жизненных проблем. Вопрос с подвохом - как вы думаете, количество голосов рядом с вопросом / ответом SO рассчитывается так же select count(*) from votesкаждый раз, или вы думаете, что, возможно, оно денормализовано? Делает ли это база данных SO плохой, а Джеффа Этвуда - сумасшедшим?
ChssPly76
@ ChssPly76, это реляционная база данных, а не объектная модель. есть таблицы, строки и столбцы, работайте в рамках этого ограничения, если вы хотите максимальную производительность, имитируйте ваши объекты для удобства ради производительности. Так следует ли хранить всю информацию о человеке в одной строке? нет, разбейте их и сгруппируйте в разные таблицы (используя мой пример из моего предыдущего комментария): «Человек», «Действия», «HealthRecords». Сохранение SUM по соображениям производительности - это совершенно другая проблема, чем хранение всех данных в 70 столбцах, чтобы избежать объединений.
КМ.
20
Должен ли numberOfTeethPulled быть частью записи Person? Нет, вероятно, его вообще не следует хранить - вы получите эту информацию из "ToothExtractionRecord", если ваша модель предметной области требует такого уровня детализации. Но это ВАШ (и, осмелюсь сказать, довольно надуманный) пример - он не имеет ничего общего с моей точкой зрения: большое количество столбцов в таблице НЕ означает, что таблица денормализована. Подумайте о контрактах на недвижимость / заказах на покупку / других финансовых документах, чтобы назвать несколько примеров. Можно ли их разбить на несколько таблиц? Да. Есть ли причина для этого? На самом деле, нет.
ChssPly76
1
+1, это было весело. Если вы создаете другую таблицу, и это будет соотношение 1: 1, вам, вероятно, следует просто включить ее в основную таблицу. Это не сэкономит место, это не будет работать намного лучше, если вы не запрашиваете данные, а не то, что они вообще не находятся в таблице. Единственная законная причина, которая приходит мне на ум прямо сейчас, это наличие конфиденциальной информации, такой как SSN, информация о кредитной карте и т.д ...
Vandel212, 03
1
Если у меня в одной таблице 15 столбцов, а в другой - 300 столбцов, первичный ключ двух таблиц будет одинаковым. Выберите один столбец в двух таблицах, будет ли существенно отличаться производительность?
от предложения нельзя отказаться
28

Разделение таблицы на несколько с меньшим количеством столбцов дает некоторые преимущества, что также называется вертикальным разбиением . Вот несколько:

  1. Если у вас есть таблицы с большим количеством строк, изменение индексов может занять очень много времени, так как MySQL необходимо перестроить все индексы в таблице. Разделение индексов на несколько таблиц может сделать это быстрее.

  2. В зависимости от ваших запросов и типов столбцов MySQL может записывать временные таблицы (используемые в более сложных запросах выбора) на диск. Это плохо, поскольку дисковый ввод-вывод может быть большим узким местом. Это происходит, если в запросе есть двоичные данные (текст или большой двоичный объект).

  3. Более широкая таблица может привести к снижению производительности запроса.

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

jonstjohn
источник
5
Почему MySQL необходимо перестроить все индексы в таблице, если изменен только один?
Петр Пеллер
Мне было интересно то же самое. Почему MySQL перестраивает все индексы в таблице? Верно ли приведенное выше утверждение?
май
13

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

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

  1. Нет повторяющихся элементов или групп элементов
  2. Отсутствие частичной зависимости от сцепленного ключа
  3. Нет зависимостей от неключевых атрибутов

Вот ссылка, которая поможет вам.

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 05
2
Однако, как в этом сценарии выполнять сложные запросы с единственной таблицей данных, вы не можете, вам нужно сильно полагаться на язык программирования и множество других вещей, чтобы заставить эту работу работать! Так что с таким же успехом я мог бы вернуться к таблице со 170 столбцами, потому что запросы «JOIN» и сверхсложное программирование, которое требуется для работы отдельных таблиц, кажутся мне пустой тратой времени. Думаю, я большой поклонник принципа KISS.
Влад Владимир Геркулес
0

Это не проблема, если все атрибуты не принадлежат одному объекту и не зависят друг от друга. Чтобы упростить жизнь, вы можете иметь один текстовый столбец с сохраненным в нем массивом JSON. Очевидно, если у вас нет проблем с получением всех атрибутов каждый раз. Хотя это полностью лишило бы смысла его хранение в СУБД и значительно усложнило бы каждую транзакцию базы данных. Поэтому не рекомендуется придерживаться этого подхода во всей базе данных.

Зишан Ч.
источник
0

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

Cегодня
источник