Сколько столбцов слишком много для таблицы SQL Server 2005?
У меня есть просьба разрешить динамической таблице иметь 1000 столбцов (случайно выбранных моими конечными пользователями). Мне это кажется плохой идеей. Это настраиваемая таблица, поэтому в ней будет смесь столбцов varchar(200) и float (float лучше всего соответствует двойному типу приложений C++). Эта база данных в основном является индексом для устаревшего приложения и служит репозиторием отчетов. Это не система записи. Приложение содержит тысячи точек данных, очень немногие из которых можно нормализовать.
Любые идеи относительно того, как это повлияет на производительность? Или идеальный размер таблицы, чтобы разделить это на части?
Поскольку я не знаю, какие поля из 20k вариантов выбора конечные пользователи выберут, нормализация таблиц неосуществима. Я могу разделить эти данные на несколько таблиц, которыми мне придется динамически управлять (поля могут быть добавлены или опущены. Затем строки удаляются, а система записи повторно анализируется, чтобы заполнить таблицу). Я предпочитаю отодвинуть и нормализовать все 20к бит данных. Но я этого не вижу.
Ответы 10
Как правило: чем шире стол, тем медленнее производительность. Многие тонкие столы предпочтительнее одного жирного стола.
Если ваш стол такой широкий, это почти наверняка проблема дизайна. Нет никакого реального правила о том, сколько столбцов предпочтительнее, я никогда не сталкивался с таблицами с более чем 20 столбцами в реальном мире. Просто сгруппируйте по родству. В конце концов, это СУБД.
Похоже, очень много. Я бы сначала убедился, что данные нормализованы. Это может быть частью вашей проблемы. Какой цели будут служить эти данные? Это для отчетов? Данные изменятся?
Я бы подумал, что стол такой ширины будет кошмаром с точки зрения производительности и обслуживания.
Я видел это при импорте данных из файла csv. CSV приходил ежедневно из устаревшей системы, и с 8-900 столбцами было быстрее просто поместить его в одну таблицу.
если таблица будет использоваться только как временное хранилище и сразу же преобразована в более подходящую форму, то я не думаю, что OP будет задавать вопрос ...
Это слишком много. Если ширина столбцов превышает 50, вы просите о проблемах с производительностью, обслуживанием кода и устранением неполадок при возникновении проблем.
из документации SQL2005:
SQL Server 2005 может иметь до двух миллиардов таблиц в базе данных и 1024 столбца в таблице. (...) Максимальное количество байтов в строке - 8 060. Это ограничение ослаблено для таблиц со столбцами varchar, nvarchar, varbinary или sql_variant, из-за которых общая заданная ширина таблицы превышает 8 060 байт. Длина каждого из этих столбцов должна оставаться в пределах 8000 байт, но их общая ширина может превышать ограничение в 8060 байт в таблице.
какова функциональность этих столбцов? почему бы лучше не разделить их на основную таблицу, свойства (таблицы поиска) и значения?
MS SQL Server имеет ограничение в 1024 столбца на таблицу, так что вы будете работать на грани этого. Используя столбцы varchar (200), вы сможете преодолеть ограничение в 8 Кбайт на строку, поскольку SQL будет хранить 8 Кбайт на странице данных, а затем переполнять данные за пределами страницы.
В SQL 2008 добавлены разреженные столбцы для подобных сценариев, когда у вас будет много столбцов с нулевыми значениями.
Использование разреженных столбцов http://msdn.microsoft.com/en-us/library/cc280604.aspx
Разреженные столбцы были бы здесь хорошим вариантом, если вы можете использовать sql 2008. Также обратите внимание на использование связанных с ним наборов столбцов msdn.microsoft.com/en-us/library/cc280521.aspx
Вот простой пример использования разреженных столбцов и наборов столбцов sqlskills.com/blogs/paul/post/…
Мне это кажется плохим дизайном.
На что следует обратить внимание:
Будет ли большинство этих столбцов содержать значения NULL?
Многие ли будут называться Property001, Property002, Property003 и т. д.?
Если это так, я рекомендую вам переосмыслить нормализацию данных.
Эти столбцы будут относиться к точкам данных в приложении. Если пользователь рекламирует поле, я ожидаю, что значения обычно не будут нулевыми.
«Если пользователь добавляет поле» указывает мне, что в противном случае оно было бы нулевым. Этот список полей динамический? Будете ли вы добавлять столбцы для поддержки добавления полей? Тогда отношение 1 ко многим в порядке.
Это будет иметь огромные проблемы с производительностью и данными. Наверное, нужно нормализовать.
Хотя сервер SQl позволит вам создать таблицу, содержащую более 8060 байт строки inteh, он НЕ позволит вам хранить больше данных, чем в ней. У вас могут быть неожиданно усеченные данные (и, что еще хуже, это может произойти только через несколько месяцев, когда исправить это чудовище будет как срочно, так и чрезвычайно сложно).
Запросить это тоже будет настоящей проблемой. Как узнать, в каком из 1000 столбцов искать данные? Должен ли каждый запрос запрашивать все 1000 столбцов в предложении where?
И идея о том, что это будет настраивать пользователь, действительно пугает. Зачем пользователю нужно настраивать 1000 полей? Большинство приложений, которые я видел, которые дают пользователю возможность настраивать некоторые поля, устанавливают небольшой предел (обычно менее 10). Если их нужно настроить так много, значит, приложение плохо определило, что на самом деле нужно клиенту.
Иногда, как разработчику, вам просто нужно встать и сказать «нет», это плохая идея. Это один из тех моментов.
Что касается того, что вы должны делать вместо этого (кроме нормализации), я думаю, нам понадобится дополнительная информация, чтобы указать вам в правильном направлении.
И, кстати, float - это неточный тип данных, и его не следует использовать для полей, в которых выполняются вычисления, если вам не нравятся неправильные результаты.
Всякий раз, когда вы чувствуете необходимость спросить, какие ограничения есть у системы, вы сталкиваетесь с проблемой проектирования.
Если бы вы спросили: «Сколько символов я могу уместить в varchar?» тогда вам вообще не следует использовать varchars.
Если вы серьезно хотите знать, подходят ли 1000 столбцов, вам отчаянно нужно реорганизовать данные. (нормализация)
Это нормально, если у системы есть разумные ограничения. Возьмите максимальную длину имени файла в D0S. 8 персонажей - это безумно мало, но с этим приходилось долго разбираться. Кроме того, 640 КБ памяти. Или 2 КБ данных подряд для SQL Server 7.
Думали ли вы о просмотре итоговой таблицы (1000 столбцов) в результате кросс-табличного запроса? Тогда в исходной таблице будет всего несколько столбцов, но много тысяч записей.
Не могли бы вы подробнее рассказать о своей проблеме? Думаю, никто толком не понимает, зачем вам эти 1000 столбцов!
Я должен не согласиться со всеми здесь ... Я знаю, это звучит безумно, но использование таблиц с сотнями столбцов - лучшее, что я когда-либо делал.
Да, многие столбцы часто имеют нулевые значения; Да, я мог бы нормализовать его до нескольких таблиц и транспонировать; Да это неэффективно
Однако невероятно быстро и легко анализировать данные столбцов бесконечным количеством различных способов.
Расточительно и неизящно - ничего полезнее вы никогда не построите!
Такой стол используется на складе. Однако иногда нам хотелось бы иметь такую гибкость и в наших базах данных.
«чем шире таблица, тем ниже производительность» Нет, это не общее правило, это зависит от характера запросов. Денормализация часто выполняется для повышения производительности определенных типов запросов.