Суть: есть типовой механизм хранения доп.реквизитов. В табличной части «Доп.реквизиты» характеристики (к примеру) есть поле свойство и значение. Поле «Значение» имеет в конфигураторе тип Характеристика. А на уровне таблиц эта штука разворачивается на несколько полей разных типов (см. скриншот) – там поле _FLD3633_* - их 7 штук.

https://i.ibb.co/bs5RZ0h/image.png

И все бы ничего, если бы одно из полей (_FLD3633_S) не имело тип фиксированной строки в 1024 символа. И даже если оно не заполнено, и значение булево, эти 2050 байт все равно заняты.

Итого: в файловой базе каждая строка таб.части доп.реквизитов имеет размер в 2140 байт или около 2 Кб. Соответственно каждый новый элемент справочника ХарактеристикиНоменклатуры с десятком доп.реквизитов (даже булево) будет иметь размер в 20Кб. Это охренеть как много.

Тоже самое и с регистром свойств, где хар-ка используется.
На SQL такого не наблюдается.

Ну и вопрос следующий, у меня много характиристик, и много доп.реквизитов к ним, боюсь не влезу в размер таблицы. Отказывать от "великого, типового, универсального БСП" решения и делать по старинке (свои реквизиты)? Может я чего-то не учитываю или делаю не так?

Проблема-то у вас какая? Нет денег на SQL и больший объём диска SSD?

(1) пусть будет так: "Нет денег на SQL".
SSD тут не причем, вопрос не в производительности на данный момент, а в объемах таблиц файловой базы.

в БСП ведь выделили строки неогр длины в отдельный реквизит с типом Строка(0), т. е. в таб. части ДополнительныеРеквизиты есть Значение и отдельный реквизит ТекстоваяСтрока.

Можно попробовать сделать, чтобы вообще все строки хранились в ТекстоваяСтрока, а не только неогр. длины, а в Значение соответственно уменьшить макс. длину строки.

(0) >> делать по старинке (свои реквизиты)?

А что в этом плохого?...
Не вижу в этом никакого криминала. В особенности с учётом существования расширений. Это как раз один из тех немногих случаев, когда расширение будет уместным для вывода таких реквизитов на форму объекта. Сам реквизит добавлять в конфигурации, а форму объекта расширять в расширении.

Конкретное решение о том где использовать допсвойства, а где добавлять реквизиты в объект необходимо принимать по месту и конкретным обстоятельствам. Там где может понадобится программная работа с реквизитом, добавляем в конфе. Те реквизиты, которые придумывает сам себе пользователь, пусть делают это через механизм допсвойств.

PS Минимизация изменений типовой конфигурации - это прекрасно. Но полный отказ от этой возможности - дикость и маразм.

ну,если хочется экономить место,то обьект в json и в blob.
просто,у той же номенклатуры есть полное наименование в 1024 символа,например,и тоже не очень понятно зачем.

опять же в sql тоже есть это поле,просто,когда в нем нет данных,sql не выделяет под него пространство,собственно,для этого тип строка переменной длины и придумывался.

кстати,в файловой базе строка неограниченной длины хранится блоками по 256 символов.

(5) "кстати,в файловой базе строка неограниченной длины хранится блоками по 256 символов"
Очень интересно. Это получается, что нет смысла делать строки неограниченной длины, если предполагается строка короче 256 символов?