Сколько столбцов слишком много для таблицы SQL Server 2005?

Question

У меня есть запрос, чтобы динамическая таблица имела 1000 столбцов (случайно выбранных моими конечными пользователями). Это кажется плохой идеей для меня. Это настраиваемая таблица, поэтому она будет содержать смесь столбцов varchar(200) и float (float лучше всего подходит для двойного типа c ++ приложений). Эта база данных в основном является индексом для унаследованного приложения и служит хранилищем отчетов. Это не система записи. Приложение имеет тысячи точек данных, очень немногие из которых можно нормализовать.

Есть идеи, как это повлияет на производительность? Или идеальный размер таблицы, чтобы разделить это тоже?

Поскольку я не знаю, какие поля из 20 тыс. Вариантов выбора будут выбраны конечными пользователями, нормализация таблиц невозможна. Я могу разделить эти данные на несколько таблиц, которыми я должен был бы управлять динамически (поля могут быть добавлены или удалены. Затем строки удаляются и система записей анализируется для заполнения таблицы.) Я предпочитаю отодвигать и нормализовать все 20 тыс. бит данных. Но я не вижу, чтобы это произошло.

Answer 1

Это пахнет как плохой дизайн для меня.

Что нужно учитывать:

Будет ли большинство этих столбцов содержать значения NULL?

Многие будут названы Property001, Property002, Property003 и т. Д.?

Если это так, я рекомендую переосмыслить нормализацию данных.

Answer 2

из документации по SQL2005:

SQL Server 2005 может иметь до двух миллиардов таблиц на базу данных и 1024 столбца на таблицу. (...) Максимальное количество байтов в строке составляет 8 060. Это ограничение смягчено для таблиц со столбцами varchar, nvarchar, varbinary или sql_variant, из-за которых общая определенная ширина таблицы превышает 8 060 байт. Длина каждого из этих столбцов должна по-прежнему находиться в пределах 8 000 байт, но их объединенная ширина может превышать ограничение в 8 060 байт в таблице.

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

Answer 3

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

Если бы вы спросили: «Сколько символов я могу вписать в варчар?» тогда вам вообще не следует использовать varchars.

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

Answer 4

MS SQL Server имеет ограничение в 1024 столбца на таблицу, поэтому вы будете работать прямо на краю этого. Используя столбцы varchar (200), вы сможете превысить ограничение 8 Кбайт на строку, поскольку SQL будет хранить 8 Кб на странице данных, а затем переполнять данные за пределами страницы.

В SQL 2008 добавлены разреженные столбцы для подобных сценариев, где у вас будет много столбцов с нулевыми значениями в них.

Использование разреженных столбцов http://msdn.microsoft.com/en-us/library/cc280604.aspx

Answer 5

Это будет иметь огромные проблемы с производительностью и данными. Это, вероятно, должно быть нормализовано.

Хотя сервер SQl позволит вам создать таблицу, содержащую более 8060 байтов строки, он НЕ позволит вам хранить больше данных, чем в ней. Вы могли бы неожиданно обрезать данные (и, что еще хуже, не раньше, чем через несколько месяцев это может произойти, когда исправление этого уродства является и неотложным, и чрезвычайно трудным).

Запрос этого также будет реальной проблемой. Как бы вы узнали, какой из 1000 столбцов искать данные? Должен ли каждый запрос запрашивать все 1000 столбцов в предложении where?

И идея, что это будет настраиваемо пользователем, действительно страшна. Зачем пользователю нужно 1000 полей для настройки? В большинстве приложений, которые я видел, которые дают пользователю возможность настраивать некоторые поля, установлен небольшой предел (обычно менее 10). Если им нужно настроить так много, то приложение не справилось с определением того, что на самом деле нужно клиенту.

Иногда, как разработчику, вам просто нужно встать и сказать нет, это плохая идея. Это один из тех времен.

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

И, кстати, float - это неточный тип данных, и его не следует использовать для полей, где выполняются вычисления, если вам не нравятся неверные результаты.

Answer 6

Как правило: чем шире таблица, тем медленнее производительность. Многие тонкие столы предпочтительнее одного толстого столика.

Если ваш стол такой широкий, это почти наверняка проблема дизайна. Нет никакого реального правила относительно того, сколько из них предпочтительнее, я никогда не встречал таблицы с более чем 20 столбцами в реальном мире. Просто группа по отношению. В конце концов, это СУБД.

Answer 7

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

Да, многие столбцы часто имеют нулевые значения; Да, я мог бы нормализовать это до нескольких таблиц и транспонировать; Да неэффективно

Однако это невероятно быстро и легко анализировать данные столбцов бесконечными различными способами

Расточительно и не элегантно - вы никогда не сделаете ничего более полезного!

Answer 8

Это слишком много. Любые более 50 столбцов, и вы просите о проблемах с производительностью, обслуживанием кода и устранением неполадок при возникновении проблем.

Answer 9

Вы думали о просмотре вашей окончательной таблицы (1000 столбцов) в результате запроса кросс-таблицы? Ваша исходная таблица будет иметь всего несколько столбцов, но много тысяч записей.

Не могли бы вы уточнить вашу проблему? Я думаю, что никто не понимает, зачем вам эти 1000 столбцов!

Answer 10

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

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