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

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

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

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

— jonstjohn
источник

5

Почему MySQL необходимо перестроить все индексы в таблице, если изменен только один?

— Петр Пеллер

Мне было интересно то же самое. Почему MySQL перестраивает все индексы в таблице? Верно ли приведенное выше утверждение?

— май

13

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

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

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

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

— 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егодня
источник