В текущем проекте, над которым я работаю, есть таблица с 126 столбцами, и наименьшее, что я видел, составляет не менее 50 столбцов. Должна ли таблица содержать меньше столбцов за стол или разделить их на новую таблицу и использовать отношения?
В вашем опыте, каковы максимальные столбцы на таблицу? Это влияет на базу данных с таким дизайном?
Джек
Как правило, лучше сначала создавать таблицы, чтобы моделировать требования к данным и удовлетворять нормам нормализации. Затем беспокоиться об оптимизации, например, сколько страниц требуется для хранения строки и т.д.
Я согласен с другими плакатами здесь, что большое количество столбцов является потенциальным красным флагом, что ваша таблица неправильно нормализована. Но в этом случае это может быть хорошо. Мы не можем сказать из вашего описания.
В любом случае разделение таблицы происходит только потому, что большое количество столбцов делает вас непростым - это не правильное средство. Это действительно вызывает какие-либо недостатки или узкое место в производительности? Вы должны измерять, чтобы не сомневаться.
Хорошее эмпирическое правило, которое я нашел, - это просто то, растет ли таблица по мере продолжения проекта,
Например:
В проекте, над которым я работаю, оригинальные дизайнеры решили включить разрешения сайта в виде столбцов в таблице пользователя.
Итак, теперь мы постоянно добавляем больше столбцов, поскольку новые функции реализованы на сайте. очевидно, это не является оптимальным. Лучшим решением было бы иметь таблицу, содержащую разрешения и таблицу соединений между пользователями и разрешения для их назначения.
Однако для другой более архивной информации или таблиц, которые просто не должны расти или должны быть кэшированы/минимизированы страницы/могут быть эффективно отфильтрованы, наличие большого стола не слишком сильно болит, пока оно не работает 't препятствует поддержанию проекта.
По крайней мере, это мое мнение.
Обычно избыточные столбцы указывают на неправильную нормализацию, но трудно судить, не имея более подробной информации о ваших требованиях.
Я могу представить время, когда может потребоваться, чтобы это было много или больше столбцов. Примеры были бы, если бы вам пришлось денормализовать и кэшировать данные - или для типа строки со многими атрибутами. Я думаю, что ключи должны избегать select * и убедитесь, что вы индексируете правильные столбцы и композиты.
Если у вас был объект, детализирующий данные в базе данных, у вас был бы один объект с 120 полями, или вы бы просматривали данные для извлечения данных, которые можно логически различить? Вы можете встраивать адресные данные с данными Клиента, но имеет смысл удалить его и поместить в таблицу адресов, даже если он сохраняет сопоставление 1:1 с Лицом.
Вниз по строке вам может потребоваться запись своего предыдущего адреса, и, разделив ее, вы удалили одну серьезную проблему, рефакторинг вашей системы.
Являются ли какие-либо из полей дублированными над несколькими строками? I.e., реплицируются детали клиента, по одному на счет-фактуру? В этом случае должна быть одна запись клиента в таблице Customers и n записей в таблице Invoices.
В одном месте, где вам не нужно исправлять неисправную нормализацию, есть таблица фактов (для аудита и т.д.), где целью является объединение данных для запуска анализа. Однако эти таблицы обычно заполняются из правильно нормированных таблиц (например, на ночь).
Это может повлиять на производительность, если люди работают с большим количеством "Выберите * из GiantTableWithManyColumns"...
Вот официальная статистика для SQL Server 2005 http://msdn.microsoft.com/en-us/library/ms143432.aspx
Имейте в виду, что это максимальные значения и не обязательно являются лучшими для удобства использования.
Подумайте о разделении 126 столбцов на разделы. Например, если это какая-то "персональная" таблица вы могли бы
Человек ID, AddressNum, AddressSt, AptNo, Province, Country, PostalCode, Telephone, CellPhone, Fax
Но вы можете разделить это на Человек ID, AddressID, PhoneID
Адрес ID, AddressNum, AddressSt, AptNo, Province, Country, PostalCode
Телефон ID, телефон, мобильный телефон, факс
Во втором случае вы также можете избавиться от репликации данных, если все люди с одинаковым адресом имеют один и тот же адрес, вместо того, чтобы копировать один и тот же текст снова и снова.
Похоже, у вас есть потенциальные проблемы с нормализацией.
Если вы действительно этого хотите, вы можете создать новую таблицу для каждого из этих столбцов (немного экстремальных) или группу связанных столбцов и присоединиться к ней по идентификатору каждой записи.
Таблица UserData в SharePoint имеет 201 поле, но предназначена для специального назначения.
По моему мнению, обычные таблицы не должны быть такими широкими.
Возможно, вы могли бы нормализовать еще немного. И прочитайте некоторые сообщения в Интернете о оптимизации таблицы.
Трудно сказать, не зная немного больше.
Ну, я не знаю, сколько столбцов возможно в sql, но одна вещь, для которой я очень уверен, что при проектировании таблицы каждая таблица является сущностью, означает, что каждая таблица должна содержать информацию либо о человеке, место, событие или объект. Так что в моей жизни я не знаю, что у этой вещи может быть много данных/информации.
Второе, что вы должны заметить, это то, что существует метод, называемый нормализацией, который в основном используется для разделения данных/информации в подраздел, чтобы можно было легко поддерживать базу данных. Я думаю, это очистит вашу идею.
Я нахожусь в подобном положении. Да, действительно есть ситуация, когда нормализованная таблица имеет, как и в моем случае, около 90, столбцы: приложение рабочего потока, которое отслеживает многие состояния, которые могут иметь случай в дополнение к переменным атрибутам для каждого состояния. Так как каждый случай (представленный записью) прогрессирует, в конечном итоге все столбцы заполняются для этого случая. Теперь в моей ситуации есть 3 логические группы (15 колос + 10 колос + 65 колос). Так что я держу его в одной таблице (index is CaseID), или я разделяю на 3 таблицы, связанные друг с другом?
Столбцы в таблице1 (публикация слияния) 246
Столбцы в таблице2 (моментальный снимок SQL Server или публикация транзакций) 1 000
Столбцы в таблице2 (моментальный снимок или транзакционная публикация Oracle) 995
в таблице, мы можем иметь максимум 246 столбцов
В таблице должно быть как можно меньше столбцов.
в таблицах SQL Server хранятся на страницах, 8 страниц - это объем
в SQL-сервере страница может содержать около 8060 байт, чем больше данных вы можете поместить на страницу, тем меньше IO вы должны сделать, чтобы вернуть данные.
Вероятно, вы хотите нормализовать (вертикальное разбиение AKA) на вашу базу данных