Оптимизация SQL: сколько столбцов в таблице? - PullRequest
15 голосов
/ 28 января 2009

В текущем проекте, над которым я работаю, есть таблица с 126 столбцами, и наименьшее, что я видел, это минимум 50 столбцов. Должна ли таблица содержать меньше столбцов на таблицу или разделить их на новую таблицу и использовать отношения?

По вашему опыту, каково максимальное количество столбцов в таблице? Влияет ли это на базу данных с таким дизайном?

Jack

Ответы [ 13 ]

19 голосов
/ 28 января 2009

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

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

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

5 голосов
/ 28 января 2009

Хорошее эмпирическое правило, которое я нашел, заключается в том, будет ли таблица увеличивать строки по мере продолжения проекта,

Например:

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

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

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

По крайней мере, это мое мнение.

3 голосов
/ 28 января 2009

Если бы у вас был объект, детализирующий данные в базе данных, у вас был бы один объект со 120 полями, или вы просматривали бы данные, чтобы извлечь данные, которые логически различимы? Вы можете встроить данные Address в данные Customer, но имеет смысл удалить их и поместить в таблицу адресов, даже если они сохраняют соответствие 1: 1 с Person.

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

Дублированы ли какие-либо поля в нескольких строках? Т.е. реплицируются ли данные клиента, по одному на каждый счет? В этом случае должна быть одна запись клиента в таблице «Клиенты» и n записей в таблице «Счета-фактуры».

Единственное место, где вам не нужно исправлять нарушенную нормализацию, это где у вас есть таблица фактов (для аудита и т. Д.), Где целью является агрегирование данных для проведения анализа. Однако эти таблицы обычно заполняются из должным образом нормализованных таблиц (например, в одночасье).

3 голосов
/ 28 января 2009

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

3 голосов
/ 28 января 2009

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

2 голосов
/ 28 января 2009

Вот официальная статистика по SQL Server 2005 http://msdn.microsoft.com/en-us/library/ms143432.aspx

Имейте в виду, что это максимумы, и они не обязательно являются лучшими для удобства использования.

Подумайте о разбиении 126 столбцов на разделы. Например, если это какая-то «личная» таблица вы могли бы иметь

Person ID, AddressNum, AddressSt, AptNo, провинция, страна, почтовый индекс, телефон, мобильный телефон, факс

Но вы могли бы разделить это на Человек ID, AddressID, PhoneID

Адрес ID, AddressNum, AddressSt, AptNo, провинция, страна, почтовый индекс

Телефон ID, телефон, мобильный телефон, факс

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

2 голосов
/ 28 января 2009

Это, безусловно, может повлиять на производительность, если люди бегают с большим количеством «Select * from GiantTableWithManyColumns» ...

1 голос
/ 28 января 2009

Похоже, у вас есть потенциальные проблемы с нормализацией.

Если вы действительно хотите, вы можете создать новую таблицу для каждого из этих столбцов (немного экстремально) или группу связанных столбцов и присоединить ее к идентификатору каждой записи.

0 голосов
/ 25 марта 2013

Столбцы в таблице1 (публикация слиянием) 246

Столбцы в таблице 2 (моментальный снимок SQL Server или публикация транзакций) 1000

Столбцы в таблице2 (моментальный снимок Oracle или публикация транзакций) 995

в таблице мы можем иметь максимум 246 столбцов

http://msdn.microsoft.com/en-us/library/ms143432.aspx

0 голосов
/ 23 июня 2009

Я в похожей позиции. Да, действительно существует ситуация, когда нормализованная таблица имеет, как в моем случае, около 90 столбцов: приложение рабочего потока, которое отслеживает множество состояний, которые может иметь дело в дополнение к переменным атрибутам для каждого состояния. Таким образом, по мере прохождения каждого случая (представленного записью) все столбцы для этого случая заполняются. Теперь в моей ситуации есть 3 логических группировки (15 столбцов + 10 столбцов + 65 столбцов). Так я должен держать его в одной таблице (индекс - CaseID), или я делю на 3 таблицы, связанные однозначным отношением?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...