|
Хранение доп.реквизитов, большой размер таблицы, БСП | ☑ | ||
---|---|---|---|---|
0
Nikoss
06.12.19
✎
08:06
|
Суть: есть типовой механизм хранения доп.реквизитов. В табличной части «Доп.реквизиты» характеристики (к примеру) есть поле свойство и значение. Поле «Значение» имеет в конфигураторе тип Характеристика. А на уровне таблиц эта штука разворачивается на несколько полей разных типов (см. скриншот) – там поле _FLD3633_* - их 7 штук.
https://i.ibb.co/bs5RZ0h/image.png И все бы ничего, если бы одно из полей (_FLD3633_S) не имело тип фиксированной строки в 1024 символа. И даже если оно не заполнено, и значение булево, эти 2050 байт все равно заняты. Итого: в файловой базе каждая строка таб.части доп.реквизитов имеет размер в 2140 байт или около 2 Кб. Соответственно каждый новый элемент справочника ХарактеристикиНоменклатуры с десятком доп.реквизитов (даже булево) будет иметь размер в 20Кб. Это охренеть как много. Тоже самое и с регистром свойств, где хар-ка используется. На SQL такого не наблюдается. Ну и вопрос следующий, у меня много характиристик, и много доп.реквизитов к ним, боюсь не влезу в размер таблицы. Отказывать от "великого, типового, универсального БСП" решения и делать по старинке (свои реквизиты)? Может я чего-то не учитываю или делаю не так? |
|||
1
yzimin
06.12.19
✎
08:58
|
Проблема-то у вас какая? Нет денег на SQL и больший объём диска SSD?
|
|||
2
Nikoss
06.12.19
✎
09:26
|
(1) пусть будет так: "Нет денег на SQL".
SSD тут не причем, вопрос не в производительности на данный момент, а в объемах таблиц файловой базы. |
|||
3
тарам пам пам
06.12.19
✎
09:37
|
в БСП ведь выделили строки неогр длины в отдельный реквизит с типом Строка(0), т. е. в таб. части ДополнительныеРеквизиты есть Значение и отдельный реквизит ТекстоваяСтрока.
Можно попробовать сделать, чтобы вообще все строки хранились в ТекстоваяСтрока, а не только неогр. длины, а в Значение соответственно уменьшить макс. длину строки. |
|||
4
unregistered
06.12.19
✎
09:58
|
(0) >> делать по старинке (свои реквизиты)?
А что в этом плохого?... Не вижу в этом никакого криминала. В особенности с учётом существования расширений. Это как раз один из тех немногих случаев, когда расширение будет уместным для вывода таких реквизитов на форму объекта. Сам реквизит добавлять в конфигурации, а форму объекта расширять в расширении. Конкретное решение о том где использовать допсвойства, а где добавлять реквизиты в объект необходимо принимать по месту и конкретным обстоятельствам. Там где может понадобится программная работа с реквизитом, добавляем в конфе. Те реквизиты, которые придумывает сам себе пользователь, пусть делают это через механизм допсвойств. PS Минимизация изменений типовой конфигурации - это прекрасно. Но полный отказ от этой возможности - дикость и маразм. |
|||
5
Сияющий в темноте
07.12.19
✎
02:26
|
ну,если хочется экономить место,то обьект в json и в blob.
просто,у той же номенклатуры есть полное наименование в 1024 символа,например,и тоже не очень понятно зачем. опять же в sql тоже есть это поле,просто,когда в нем нет данных,sql не выделяет под него пространство,собственно,для этого тип строка переменной длины и придумывался. кстати,в файловой базе строка неограниченной длины хранится блоками по 256 символов. |
|||
6
Провинциальный 1сник
07.12.19
✎
06:55
|
(5) "кстати,в файловой базе строка неограниченной длины хранится блоками по 256 символов"
Очень интересно. Это получается, что нет смысла делать строки неограниченной длины, если предполагается строка короче 256 символов? |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |