Сколько столбцов - слишком многие для таблицы SQL Server 2005?
Я думаю, вам нужно объявить поле USR_ID и соответствующую последовательность в вашей сущности
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "XXXX")
@SequenceGenerator(sequenceName = "YYYY", allocationSize = 1, name = "XXXX")
Long USR_ID;
9 ответов
Это пахнет как плохой дизайн мне.
Вещи рассмотреть:
Будут большинство тех столбцов быть содержать Нулевые значения?
Многих назовут Property001, Property002, Property003, и т.д....?
Если так, я рекомендую заново продумать нормализацию данных.
из документации SQL2005:
SQL Server 2005 может иметь до двух миллиардов таблиц для каждой базы данных и 1 024 столбца за таблицу. (...) максимальное количество байтов на строку 8,060. Это ограничение ослаблено для таблиц с varchar, nvarchar, varbinary, или sql_variant столбцов, которые заставляют общую определенную таблицу width превышать 8 060 байтов. Длины каждого из этих столбцов должны все еще находиться в пределах предела 8 000 байтов, но их объединенные ширины могут превысить 8 060-байтовый предел в таблице.
какова функциональность этих столбцов? почему не лучше разделяет их на основную таблицу, свойства (справочные таблицы) и значения?
SQL Server MS имеет предел 1 024 столбцов за таблицу, таким образом, Вы собираетесь быть рабочим правом на краю этого. Используя varchar (200) столбцы, Вы сможете пойти мимо 8k байта на предел строки, так как SQL сохранит 8k на странице данных и затем переполнит данных за пределами страницы.
2008 SQL добавил Редкие Столбцы для сценариев как это - где у Вас будет много столбцов с нулевыми значениями в них.
Использование редких столбцов http://msdn.microsoft.com/en-us/library/cc280604.aspx
Каждый раз, когда Вы чувствуете потребность спросить, что ограничивает систему, имеет, у Вас есть проблема проектирования.
Если Вы спрашивали, "Сколько символов я могу вписаться в varchar?" затем Вы не должны использовать varchars вообще.
Если Вы серьезно хотите знать, хорошо ли 1 000 столбцов, то отчаянно необходимо реорганизовать данные. (нормализация)
Как правило: чем шире таблица, тем медленнее производительность. Много тонких таблиц предпочтительны для одной толстой путаницы таблицы.
Если Ваша таблица - то, что широкий это - почти наверняка вопросы проектирования. Нет никакого реального правила о том, сколько предпочтительно, я действительно никогда не сталкивался с таблицами больше чем с 20 столбцами в реальном мире. Просто группа отношением. Это - RDBMS, в конце концов.
Это будет иметь огромную производительность и проблемы данных. Это, вероятно, должно быть нормализовано.
В то время как SQL-сервер позволит Вам составить таблицу, которая имеет больше чем 8 060 байтов inteh строка, он НЕ позволит Вам хранить больше данных, чем это в нем. У Вас могли быть неожиданно усеченные данные (и хуже, только когда несколько месяцев спустя мог это происходить, которым время, фиксируя это чудовище является и срочным и exptremely трудно).
Запросы этого также будут настоящей проблемой. Как Вы знали бы который из 1 000 столбцов искать данные? Каждый запрос должен попросить все 1 000 столбцов в где пункт?
И идея, что это было бы настраиваемо пользователем, страшна действительно. Почему пользователю были бы нужны 1000 поля для настройки? Большинство приложений, которые я видел, которые дают пользователю шанс настроить некоторые поля, устанавливает маленький предел (обычно меньше чем 10). Если существует так очень, они должны настроить, то приложение не сделало хорошего задания определения, в чем на самом деле нуждается клиент.
Иногда как разработчик просто необходимо встать и сказать "нет", это - плохая идея. Это - одно из тех времен.
Относительно того, что Вы shoud делаете вместо этого (кроме нормализуют), я думаю, что нам было бы нужно больше информации для указания на Вас в правильном направлении.
И BTW, плавание является неточным типом данных и не должно использоваться для полей, где вычисления происходят, если Вам не нравятся неправильные результаты.
Походит на очень много. Я сначала удостоверился бы, что данные нормализованы. Это могло бы быть частью Вашей проблемы. Какой цели эти данные будут служить? Это для отчетов? Данные изменятся?
Я думал бы, что таблица, настолько широкая, будет производительностью кошмара и мудрый обслуживанием.
Это - слишком многие. Больше, чем 50 столбцов шириной и Вы напрашиваетесь на неприятности в производительности, кодируете обслуживание и поиск и устранение неисправностей, когда существуют проблемы.
Вы думали о просмотре Вашей заключительной таблицы (на 1 000 столбцов) как результат перекрестного запроса? Ваша исходная таблица затем имела бы всего несколько столбцов, но много тысяч записей.
Можно ли уточнить проблему? Я думаю, что никто действительно не понимает, почему Вам нужны эти 1 000 столбцов!