| |
|
|
| | Скажите как в таблице создать больше 255 полей ? | |
| |
| |
| |
|
|
| | Вариант1 - переделатьт аблицу, ибо если в ней болше 255 полей, то ИМХО - что то там неправильно ( неправильно спроектирована база данных )
Вариант2-
Использовать SQL-server | |
| |
| |
| |
|
|
| | вообще конечно 255 полей- это многовато (см. ответ ув. Мюллера) , но если вы уверены что они все должны быть в одной таблице, то делайте 2 таблицы общим ключевым полем | |
| |
| |
| |
|
|
| | Блиц - опрос для всех, если не возражаете?
Какое максимальное количество полей таблицы приходилось иметь.
Я в одном случае сознательно пошел на денормализацию
(два разных типа продукции, у которых общими были 10 полей, из них 6 расчетных
(расчет сложный, поэтому хранил расчетные значения)).
В итоге получилось 51 поле.
Довольно неудобно было ворочаться в таком количестве полей. | |
| |
| |
| |
|
|
| | точно не помню, но не больше 50, но ....
я никогда не автоматизировал медицину, только слегка касался, а там... в общем вполне допускаю необходимость более 255 атрибутов по одному объекту | |
| |
| |
| |
|
|
| | Стало быть нужны таблицы справочники?
Там алколоиды, закусоиды, опохмелоиды,..... | |
| |
| |
| |
|
|
| |
общем вполне допускаю необходимость более 255 атрибутов по одному объекту
|
Сейчас у мну в проекте по одному объекту будет несколько сотен параметров. Но при этом максимальное число полей в таблицах не превышает 27.
Все это решается путем создания нескольких ( или нескольких десятков ) таблиц в котором параметы объекта вытягиваются /заносятся по ключу объекта.
Правда при этом число записей в таблицах растет в геометрической прогрессии.
Но SQLServer на то и придуман, чтобы работать с большим числом записей. | |
| |
| |
| |
|
|
| | а я только что посчитал кол-во полей в моей таблице "Сделанные расчеты" - 140шт.
90% полей выборные из формы-калькулятора, остальные результаты вычислений на основе этих полей. Расчеты сложнейшие, поэтому проще было сохранить результаты...
можно конечно было разбить таблицу на 3, но решил пока так оставить
или все же лучше разбить?  | |
| |
| |
| |
|
|
| | Как вариант - выкинуть нафик расчетные поля. Алгоритмы расчетов - в отдельную(отдельные) функции. При выборке данных - использование этой(этих) функций.
Таблицу лучше разбить на несколько. Поиск/запись - по ключам.
Но это ИМХО | |
| |
| |
