Сколько столбцов слишком много для таблицы SQL Server 2005?
у меня есть запрос, чтобы динамическая таблица имела 1000 столбцов(случайно выбранных моими конечными пользователями). Мне кажется, это плохая идея. Это настраиваемая таблица, поэтому она будет иметь смесь varchar(200) и float столбцы (float лучше всего соответствует типу приложений c++ double). Эта база данных в основном является индексом для устаревшего приложения и служит хранилищем отчетов. Это не система записи. Приложение имеет тысячи точек данных очень немногие из которых могут быть нормализованы из.
любые идеи о том, каковы последствия для производительности этого? Или идеальный размер таблицы, чтобы разделить это тоже?
поскольку я не знаю, какие поля из 20k стоят выбора, конечные пользователи выберут нормализацию таблиц нецелесообразно. Я могу разделить эти данные на несколько таблиц, которыми мне придется динамически управлять (поля могут быть добавлены или опущены. Затем строки удаляются, и система записи повторно анализируется для заполнения таблицы.) Мое предпочтение это отодвинуть и нормализовать все 20k бит данных. Но я не думаю, что это произойдет.
10 ответов
Это пахнет плохой дизайн для меня.
вещи для рассмотрения:
будет ли большинство этих столбцов содержать значения NULL?
многие будут называться Property001, Property002, Property003 и т. д...?
Если это так, я рекомендую вам пересмотреть нормализацию данных.
из документации SQL2005:
среда SQL Server 2005 может иметь до двух миллиардов таблиц в базе данных и 1024 столбцов в таблице. (...) Максимальное количество байтов в строке-8,060. Это ограничение ослаблено для таблиц с столбцами varchar, nvarchar, varbinary или sql_variant, из-за которых общая ширина таблицы превышает 8,060 байт. Длина каждого из этих столбцов должна по-прежнему находиться в пределах 8 000 байт, но их общая ширина может превышать 8 060 байт байт в таблице.
какова функциональность этих столбцов? почему бы не разбить их на главную таблицу, свойства (таблицы поиска) и значения?
всякий раз, когда вы чувствуете необходимость спросить, какие ограничения имеет система, у вас есть проблема с дизайном.
Если бы вы спросили: "сколько символов я могу вписать в varchar?- тогда тебе вообще не следует использовать варчаров.
Если вы серьезно хотите знать, если 1000 столбцов в порядке, то вам отчаянно нужно реорганизовать данные. (нормализация)
MS SQL Server имеет ограничение в 1024 столбца на таблицу, поэтому вы будете работать прямо на краю этого. Используя столбцы varchar (200), вы сможете пройти ограничение 8K байт на строку, так как SQL будет хранить 8k на странице данных, а затем переполнять данные за пределами страницы.
SQL 2008 добавил разреженные столбцы для таких сценариев , где у вас было бы много столбцов с нулевыми значениями в них.
Использование Sparse Столбцы http://msdn.microsoft.com/en-us/library/cc280604.aspx
Как правило: чем шире стол, тем медленнее производительности. Много тонких столов предпочтительнее одного жирного месива стола.
Если ваша таблица такая широкая, это почти наверняка проблема дизайна. Нет реального правила о том, сколько предпочтительнее, я никогда не сталкивался с таблицами с более чем 20 столбцами в реальном мире. Просто группировка по родству. В конце концов, это РСУБД.
Это будет иметь огромные проблемы с производительностью и данных. Вероятно, его нужно нормализовать.
хотя SQl server позволит вам создать таблицу с более чем 8060 байтами в строке, она не позволит вам хранить больше данных, чем в ней. Вы могли бы неожиданно усе (и хуже, пока несколько месяцев спустя это могло произойти за это время исправить это уродство актуальная и exptremely жесткий).
запрос это также будет реальной проблемой. Как вы знаете, что из 1000 столбцов искать данные? Должен ли каждый запрос запрашивать все 1000 столбцов в предложении where?
и идея, что это будет настраиваемый пользователь действительно страшно. Зачем пользователю понадобилось настраивать 1000 полей? Большинство приложений, которые я видел, которые дают пользователю возможность настроить некоторые поля, устанавливают небольшой предел (обычно меньше 10). Если есть то, что им нужно настроить, то приложение не сделало хорошую работу по определению того, что клиент действительно нуждается.
иногда как разработчик вам просто нужно встать и сказать нет, это плохая идея. Это один из таких случаев.
Что касается того, что вы делаете вместо этого (кроме нормализации), я думаю, нам понадобится больше информации, чтобы указать вам в правильном направлении.
и кстати, float является неточным типом данных и не должен использоваться для полей, где происходят вычисления, если вам не нравятся неправильные результаты.
Я должен не согласиться со всеми здесь.....Я знаю, это звучит безумно, но использование таблиц с сотнями столбцов-лучшее, что я когда-либо делал.
Да многие столбцы часто имеют значения null; Да, я мог бы нормализовать его до нескольких таблиц и транспонировать; Да это неэффективно
однако это невероятно быстро и легко анализировать данные в бесконечных разному
расточительный и неэлегантный-вы никогда не будете строить ничего, как полезно!
Это слишком много. Более 50 столбцов в ширину, и вы просите проблемы с производительностью, обслуживанием кода и устранением неполадок при возникновении проблем.
кажется, ужасно много. Сначала я хотел бы убедиться, что данные нормализованы. Это может быть частью вашей проблемы. Какой цели будут служить эти данные? Это для отчетов? Изменятся ли данные?
Я бы подумал, что такая широкая таблица будет кошмаром производительности и обслуживания.
вы думали о просмотре окончательной таблицы (1000 столбцов) в результате запроса перекрестной таблицы? Тогда исходная таблица будет иметь несколько столбцов, но много тысяч записей.
не могли бы вы подробнее рассказать о своей проблеме? Я думаю, что никто не понимает, зачем вам нужны эти 1000 столбцов!