![]() |
#1 |
Участник
|
Предельное количество полей в таблице
Добрый день.
Коллеги, подскажите, пожалуйста, какое максимальное количество полей может хранить в себе таблица Axapt - ы, На текущий момент в одной из таблиц (конкретно в InventTable) уже хранится 291 поле, а постановщик ТЗ просит добавить в эту же таблицу еще 264 поля. ![]() |
|
![]() |
#2 |
Молодой, подающий надежды
|
А почему так важно добавить поля именно в саму таблицу, а не сделать новую и привязать к исходной по ключу?
В 2012, например, это вообще не проблема, используя Table extension framework Последний раз редактировалось pedrozzz; 15.09.2015 в 13:28. |
|
|
За это сообщение автора поблагодарили: Stitch_MS (6), alex55 (1). |
![]() |
#3 |
Участник
|
Создание дополнительной таблицы возможно, но все равно рано или поздно возникнет тот же вопрос, поскольку каждый раз создавать новую таблицу это не есть правильно
![]() |
|
![]() |
#4 |
Молодой, подающий надежды
|
Предельное количество полей не знаю, но думаю для любых целей хватит с лихвой. Тут проблема может возникнуть на этапе выполнения запросов, где с таблицами такого размера легко упереться в ограничение АОС на суммарный внутренний размер записей в объединенном операторе SELECT и словить проблемы с производительностью. Несмотря на то, что в новых версиях проверка запросов на ограничение выборки полей является частью BP, многие разработчики по-прежнему на это забивают.
|
|
![]() |
#5 |
Участник
|
У нас на AOS - е размер буфера установлен в 114, объем одной записи таблицы InventTable (info(int2str(SysDictTable::newTableId(tableNum(InventTable)).recordSize()))
![]() |
|
![]() |
#6 |
Гость
|
Подозреваю что в районе 1024
http://dynamicsuser.net/forums/p/48273/248368.aspx что больше связано имхо с ограничениями SQL Server https://technet.microsoft.com/en-us/...v=sql.80).aspx Columns per base table 1,024 PS но вообще проще и правильнее решать через атрибуты номенклатуры а там нет ограничений имхо. А то завтра вам постановщик предложит еще тысячу полей и вам делать. В случае же атрибутов делать он может сам. Последний раз редактировалось axm2013; 15.09.2015 в 14:50. |
|
![]() |
#7 |
Злыдни
|
Цитата:
Сообщение от axm2013
![]() Подозреваю что в районе 1024
http://dynamicsuser.net/forums/p/48273/248368.aspx что больше связано имхо с ограничениями SQL Server В письме я уже ответил, но продублирую здесь: при проектировании таблицы не стоит забывать о длине строки, При превышении длины 8060 байт столкнетесь с понижением производительности. См. https://technet.microsoft.com/ru-ru/...=SQL.105).aspx. Обратите внимание на совет с нормализацией таблиц с большим количеством столбцов и с наличием большого количества столбцов с varchar, nvarchar и т.п.
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании. |
|
|
За это сообщение автора поблагодарили: trud (2), Logger (3), gl00mie (2). |
![]() |
#8 |
Участник
|
Цитата:
![]() Я так понимаю, постановщику нужно неограниченное количество возможных видов характеристик номенклатуры. Если они только хранятся (т.е. подбора товаров по их комбинациям и прочих особых требований нет), то почти наверняка придётся изменить способ их хранения, скорее всего, на EAV (https://en.wikipedia.org/wiki/Entity...%93value_model). И хотя это общеизвестный антипаттерн в реляционных СУБД (даже при аккуратной реализации), чтобы решить задачу, на это придётся пойти (да, придётся переписать весь связанный с характеристиками код, включая их отображение в формах и обмен с внешними системами, и перенести данные). |
|