15.09.2015, 13:15 | #1 |
Участник
|
Предельное количество полей в таблице
Добрый день.
Коллеги, подскажите, пожалуйста, какое максимальное количество полей может хранить в себе таблица Axapt - ы, На текущий момент в одной из таблиц (конкретно в InventTable) уже хранится 291 поле, а постановщик ТЗ просит добавить в эту же таблицу еще 264 поля. |
|
15.09.2015, 13:19 | #2 |
Молодой, подающий надежды
|
А почему так важно добавить поля именно в саму таблицу, а не сделать новую и привязать к исходной по ключу?
В 2012, например, это вообще не проблема, используя Table extension framework
__________________
Кононов Пётр Последний раз редактировалось pedrozzz; 15.09.2015 в 13:28. |
|
|
За это сообщение автора поблагодарили: Stitch_MS (6), alex55 (1). |
15.09.2015, 13:28 | #3 |
Участник
|
Создание дополнительной таблицы возможно, но все равно рано или поздно возникнет тот же вопрос, поскольку каждый раз создавать новую таблицу это не есть правильно
|
|
15.09.2015, 13:34 | #4 |
Молодой, подающий надежды
|
Предельное количество полей не знаю, но думаю для любых целей хватит с лихвой. Тут проблема может возникнуть на этапе выполнения запросов, где с таблицами такого размера легко упереться в ограничение АОС на суммарный внутренний размер записей в объединенном операторе SELECT и словить проблемы с производительностью. Несмотря на то, что в новых версиях проверка запросов на ограничение выборки полей является частью BP, многие разработчики по-прежнему на это забивают.
__________________
Кононов Пётр |
|
15.09.2015, 14:01 | #5 |
Участник
|
У нас на AOS - е размер буфера установлен в 114, объем одной записи таблицы InventTable (info(int2str(SysDictTable::newTableId(tableNum(InventTable)).recordSize())) равен 9593 байт, а суммарный объем информации для формы InventTable (для одной записи) равен 16626 байт
|
|
15.09.2015, 14:32 | #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. |
|
16.09.2015, 08:48 | #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). |
16.09.2015, 21:48 | #8 |
Участник
|
Цитата:
Я так понимаю, постановщику нужно неограниченное количество возможных видов характеристик номенклатуры. Если они только хранятся (т.е. подбора товаров по их комбинациям и прочих особых требований нет), то почти наверняка придётся изменить способ их хранения, скорее всего, на EAV (https://en.wikipedia.org/wiki/Entity...%93value_model). И хотя это общеизвестный антипаттерн в реляционных СУБД (даже при аккуратной реализации), чтобы решить задачу, на это придётся пойти (да, придётся переписать весь связанный с характеристиками код, включая их отображение в формах и обмен с внешними системами, и перенести данные). |
|
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|