Имя: Пароль:
1C
1С v8
Хранение доп.реквизитов, большой размер таблицы, БСП
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 символов?