Обратился ко мне тут один клиент. Обратился с "мелкой" задачкой, но в процессе общения, по привычке, глянул я на базу...
Итак - база ПУБ (да-да живут еще такие:)), т.е. аки "Комплексная" - и с регистрами, и с проводками...
НО, по размеру файлов, самые "толстые" - DT-шки "Счетов-фактур" и "Реализаций". обе уже "перевалили" 1,3Гб (пока не на много, но динамику никто не мерял).
Ибо "понадобавлено" куча всяких реквизитов мутных в табличную часть. Большинство числовых.
Следующий по "толщине" - 1SBLOB, и то, только из-за того, что в "некоторых" местах используется дебильный подход хранения "неких" ТЗ в строковом реквизите неограниченной длины. И тот мегабайт 800 всего...
Далее - файл проводок 1SENTRY ~ 700 Мб...
Регистры, на первый взгляд, правильные - RA гораздо больше RG...
В общем, хочу уменьшить размер числовых полей (пару реквизитов вообще удалить можно), дабы сократить размеры файлов.
Вопрос в том, насколько сократить, чтоб и лишнего не оставить и данные не запороть.
Максимальные значения реквизитов за весь период существования базы я выдернул.
Размер максимальных значений - 9 (включая "." и дробную часть). Просто, реквизиты с разной точностью
Один из реквизитов имеет "Итог по колонке". (Ну его, по сути, можно оставить в покое - там 14.2)
Сколько "припуска по длине" оставить?

(0) отчетом выявить максимальную "сумму".
Иначе, если порежешь по максимальному значению хранения, в сумме вылетишь за предел разрядности

+ в пубе можно кастрировать 41 счет, оставив там только сумму, без аналитики по номенклатуре, её можно смотреть отчетом по партиям, короче, с регистров.

ну и твоё файло проводок похудеет в разы.

Как-то подозрительно поджарая база для таких DT. Наверное, там в табличных частях помимо числовых есть ещё и строковые, типа "Примечание",Строка,50 и "Страна",Строка,50. Такие реквизиты лучше в справочники или перечисления закидывать. А что касается числовых - послушай Ёпрста, где "Итог по колонке" есть, там надо смотреть максимальное количество разрядов в Итог() по документу, а про остальные - ну добавь единичку к максимальным значения и режь.
А выгрузка/загрузка не уменьшит тебе DT-шки? А то может там просто удаленные записи от предыдущих свёрток болтаются.

(1) Вот я, вроде как, об этом и хотел спросить - т.е чтоб "черные" запросы потом не тупили.
Ибо, по счетам-фактурам не встречал пока, а по отгрузкам - пара-тройка, прям самых ходовых у них, отчетов данные собирают.
(3) Да файло проводок особо не беспокоит.
(4) "А выгрузка/загрузка не уменьшит тебе DT-шки?" - её можно и не дождаться:) Загрузку, я имею в виду.
"А то может там просто удаленные записи от предыдущих свёрток болтаются" - нет, это первым делом проверил.
Там порядка 1000 отгрузок в день.

Ну если пуб - значит давно сидят.
С теми значениями что приведены я бы ничего не делал, только проблему 1гб подправил бы и всё.

1000 отгрузок в день - отгрузки скорее всего мелкие по ТЧ, иначе давно бы вывалились

(6) Серёг, приветствую.
Да - сидят давно, причём глубоко. И при этом работать умудряются до сих пор:)
(7) Вангуешь правильно - строк 10 не более.
Ёпрст - вот по поводу : "отчетом выявить максимальную "сумму"" - какую сумму выявить?
Это ж табличные части доков... Или глянуть какие максимальные суммы получаться за весь период существования базы?

(8) видел бы ты ту базу торговли, которую мне приходится подкручивать одному клиенту... Я на неё даже чихнуть опасаюсь...

Итоги по колонке документов максимальные посмотри я так понял
А то если точность реквизита сделаешь 3 то есть макс 999, и 10 строк то итог по колонке 9990 и не ведёт в три разряда

А кстати где итог по колонке хранится?

Опять же, если стопудово период старый закрыт и доки как таковые по сути уже не нужны то можно тупо ТЧ этих доков почистить.
Но тут сильно зависит каких костылей понаставлено

(9) Чихнуть в каком плане? Тоже распухла до грани и еле ворочается?:)
(11) Итог есть только у одного реквизита - "Всего"
(12) Нет. В том то и дело, что кто-то (пока не выяснил кто) базу уже резал.
И не однократно, судя по каталогам с одноименным названием+датой, лежащим рядом с базой.
В текущей доки с 01.01.2020

(13) (9) как это вообще работает...

(14) Я сам в шоке, если честно:)
Ща неспешно ковыряю MD-шник... Мляяя... Обнять и плакать...
Он даже полный синтакс-контроль не проходит:)
Причем "ругань контролёра" по большей части, примерно такая:

глЗатратыПоПродукции(Выбор.Номенклатура, Выбор.Спецификация, Выбор.Количество, ДатаДок, ТаблицаЗатрат<<?>>);
{Документ.СдельныйНаряд.Форма.Модуль(580)}: Недостаточно фактических параметров

глПоказатьТаблицу(Таб,"ЖурналУчетаСчетовФактур","Журнал учета счетов-фактур",,,,,<<?>>2);
{Отчет.ЖурналУчетаСчетовФактур1137.Форма.Модуль(521)}: Слишком много фактических параметров

Т.е. и нехватка и избыток параметров для процедур и функций глобального (штатного причём) модуля. :)
Видимо, объекты, откуда сии ошибки валятся давно не используются, иначе у меня и мыслей даже нет - "КАК"

(15) Ну, это кто-то порезвился...
В моей базе ПУБ этого не наблюдается.

(0)
>Сколько "припуска по длине" оставить?
общая длина - вопрос инфляции.
точность - в вычислениях можно нарваться на погрешность.

(17)
+в коде конфы мб зависимость от длины,точности.

(15) Ну это-то как раз классика рукожопства - накатить обновление конфигурации через объединение со снятыми галками изменённых в локальной базе объектов, без последующего ручного обновления этих объектов. В частности - глобального модуля. Можно глянуть журнал регистрации по событию "Ошибка" - за последние год-полгода, были ли им какие критичные вещи тут. Ну и при желании и оплате - довести мдшник до нормального. Благо обновления в ПУБе уже вряд ли будут сколь-нибудь значимыми.
(11) DH
(18) Ну там ТС виднее что там за реквизиты такие чудные. Чего-нибудь типа "Квант", "Мест", "Единиц в месте", "Объем", "Площадь", или изменяемые параметры продукции. Вряд ли при продуманном уменьшении точности это будет критично и завязано на конфигурацию. Наверняка там ТС уменьшением длины обойдётся.
(5) "её можно и не дождаться:) Загрузку, я имею в виду." - а вот это вряд ли. Судя по размерам база терпимая, RA небольшие, 1SKKTL тоже, раз про них не пишешь. Ну это, просто был как вариант. Потому что, согласен, разные чудесные базы встречаются. Был клиент имевший типовую файловую бухгалтерию со справочником ОС - под несколько сотен тысяч позиций (сдача в аренду) и общим размером всего-то полгига. Не загружалась...

(17) Точность оставлю в покое.
(18) Там больше зависимостей от НайтиПоКоду и НайтиПоНаименованию :)
(19) Нее, скорей всего, переписали глобальные процедуры и функции, просто обращение к ним переделали только в "нужных" местах, там где ошибку выдавало))
Так как релиз там 276! Я глянул - текущий 411 от 28.02.22. Самый ранний, до которого я смог "дотянуться" - 367 от 29.10.15. Так что, походу, как поставили изначально, так и работают