Есть регистр РегистрацияИзмененияВОбъектах
Там хранится история, вот такого вида:
https://yadi.sk/i/04_XNmDM-tCC0A
Записей сейчас 7 314 125, размер таблицы был 11.6 Гб (11 628 600 Кб).

Структура регистра:
https://yadi.sk/i/JpPAL978Dj_O1g
Все текстовые поля длинной 100 символов, переменной длины.
Остальные 5 полей:
Дата, ДатаОбъекта = ДатаВремя
КодНомерОбъекта= 11 символов.
GUID = 36 символов.
НомерСтрокиТЧ = Число 6.

Решил оптимизировать размер таблицы. Посчитал максимальную длину для каждого текстового реквизита.
Поля стали размером:
ИмяТабличнойЧасти = 32
ИмяРеквизита = 48
ТипОбъекта = 15
ИмяОбъекта = 56
ПредставлениеОбъекта = 100
ПредставлениеЗначенияРеквизита_Старое = 100
ПредставлениеЗначенияРеквизита_Новое = 100
Пользователь = 30
Компьютер = 20
РежимЗаписиПроведения = 33
Синоним = 54

Сокращение значительное, около 50%. Ожидал сокращения размера таблицы на 20-30%.

После реорганизации таблицы и сжатия SQL.
Размер таблицы стал 11 Гб (11 027 464 Кб)

Получилось всего на 5% уменьшить таблицу.

Решил дальше эксперимент проводить и поставил всем текстовым реквизитам вместо переменной фиксированную длину.
Получил двукратное увеличение таблицы.
Размер таблицы стал 22Гб (22 137 896 Кб)
https://yadi.sk/i/TdKcm0hUYipieA

А чего ты ждал?

(0)

Что ты наделал? Эту статью должен был написать совсем другой человек, разместить у себя на сайте и скинуть сюда ссылку!

P.S.
Твой 500Гб SSD с удивлением (вот хозяину делать нефиг) наблюдает за этими экспериментами,
приговаривая:
- Хозяин! Почитай книжки по sql. Они rules.

(1) 20-30% сокращения размера таблицы.
Увидел результат, решил с сообществом поделится.
В книжках читал, но то теория, а то решил на практике проверить.

размер страницы как был 8Кб, так и остался

(4) То есть на каждый текстовый реквизит минимум по 8кб занимает?

(5) каждое значение разбивается на страницы, кратные 8кб, емнип

раз: https://docs.microsoft.com/ru-ru/sql/t-sql/data-types/char-and-varchar-transact-sql?view=sql-server-ver15
два: https://docs.microsoft.com/ru-ru/sql/relational-databases/databases/estimate-the-size-of-a-heap?view=sql-server-ver15

(6) (7) Спасибо ))

(0) В измерениях оставить Ссылка, Дата. В ресурсах Хранилище, в которое писать массив структур со всеми остальными полями регистра.
Если меняли 3 записи в ТЧ по документу, то добавлять 1 запись в регистр (3 элемента массива со структурой в хранилище), а не 3 раза как сейчас.
До 200-300мб может ужмется

Чтобы реально сократить размер этого безумия надо пересматривать подход.
Либо переходить на типовое версионирование, либо разбивать на несколько отдельных таблиц. Например, в одной хранить ключи изменения (дата, ссылка на объект и его параметры, пользователь, компьютер), во второй сами изменения (имена реквизитов и табличных частей, старые и новые значения) с привязкой к ключам. Тогда на один ключ (запись в первой таблице) будет множество записей об изменениях во второй.
Подумать на тему - нет ли тут лишнего. Например, ПредставлениеОбъекта и Синоним (нафига они нужны?).
Как вариант рассмотреть (9). Хотя, я так полагаю это не очень подойдёт, если эти данные нужны для построения каких-либо отчетов. Хранить изменения в хранилище в виде структуры может быть удобно, когда эти данные используются исключительно для просмотра истории по одному объекту.

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

А еще поля могут быть индексируемыми,и тут размер очень увеличивается.

И вообще.
А нафига париться о размере этой таблицы? Для SQL 5Гб туда, 5Гб сюда - никакой особой разницы.
Если так уж сильно парит, то тупо рассмотреть вопрос об удаление информации о старых изменениях.
Например, если делаете ежегодный бекап базы на вечное сохранение в сейф, то после его изготовления запускайте очистку этого регистра с датами изменений старше двух лет (например). В архивах данные всегда останутся, а в рабочей базе истории за пару лет более чем достаточно в 99.9% случаев. На оставшиеся 0.1% есть архивы.

(0) Гений 1с тебе глаза расцарапает. Ты у него целое открытие сп..дил

(0)
https://youtu.be/uO80v4dzBUs

а сделал бы служебный справочник и вообще бы съэкономил 90%

(3) Это ты молодец, что решил сам проверить. Продолжай в том же духе. В книжках бывает врут, бывает недоговаривают.

Предлагаю следующий эксперимент. Писать текстовые логи в текстовые файлы (или хотя бы в ЖР). Если делать это согласно лучшим практикам, со сжатием, ротацией и т.д., то на быстрых дорогих SSD столько полезного места освободится!.. Которому можно найти лучшее применение.

(0) ну и наркомания. Под стать Г1Су

А почему не хранилище двоичных данных новое?

Вангую что место уменьшилось ибо пересчет страниц был. (а ля дефрагментация) По идее же наоборот увеличиться должно было

>>Записей сейчас 7 314 125, размер таблицы был 11.6 Гб (11 628 600 Кб)
...
>>Размер таблицы стал 11 Гб (11 027 464 Кб)
...
>>Сокращение значительное, около 50%. Ожидал сокращения размера таблицы на 20-30%.

Я не понял

(20) В (0) не знал, что "переменной длины" важно именно для хранения данных в SQL.

(9) (10) (11) (12) (18)  Спасибо за предложенные варианты оптимизации. Но пока задача такая не стоит. Это результат работы БД за 5 лет. Данные старше 5 лет удаляю периодически.
Хранилище значений не подходит иногда приходится для поиска косяков использовать сложные отборы в данном регистре.
В индексы сразу не глянул, точно размер данных 4Гб, индексы 7,5Гб. Индексы пересмотрел, выключил пару лишних.
(16) Прошли те времена когда SSD стоили космических денег, плюс минус 10Гб
(13) (14) (17) Посмеялся вместе с вами. Данное решение было скачено лет 7 назад с просторов инфостарта. Цель контролировать историю справочников и документов. Из плюсов данного решения простота установки и работы с ним. Там шла cf, её нужно было просто накатить на любую свою конфигурацию и потом в режиме предприятия отметить галочками какие документы будут записаны в историю. Помимо документов галочками отмечаются и реквизиты которые нужно контролировать. Из плюсов как я писал простота установки, вся система буквально запускается за 1 час. Из минусов не оптимальное хранение данных. Решения ведь подбираются под ТЗ. Данный регистр чем то похож на Журнал регистрации, только работает без тормозов и позволяет видеть не только то что с объектом работали, но и знать какую важную информацию в нём поменяли. Со временем я конечно доработал решение. Например вывел в отдельный регистр для хранения истории номенклатуры, так как у нас большой ассортимент номенклатуры 700 000 и в нём активно меняют реквизиты, данных в истории там не меньше чем в этом регистре.
(19) Нет, я перед обновлением конфигурации запустил сжатие таблиц SQL, потом накатил конфигурацию и ещё раз запустил сжатие таблиц SQL
(20) Если суммарно посчитать сокращение длины всех реквизитов, то она уменьшились на 50%. Были все длиной по 100, а стали от 15 и выше.

(11) После удаления индексов, таблица уменьшилась значительно. Спасибо, сразу на это внимание не обратил.
Было:
11 Гб

Стало:
7.3 Гб из них половина размера, это индексы.
https://yadi.sk/i/Db6LF67JwzEjcw

(0), (22), (23) Так в чем смысл перехода от переменной длинны к более коротким полям? Кроме непредсказуемого поведения, когда служебные поля превысят установленное ограничение.

(24) Смысла нет, согласен. Убрал сейчас все индексы, размер стал 5Гб, скорость отборов практически не изменилась.

Переопредели механизм хранения РежимЗаписиПроведения - ещё +-5% сэкономишь.

(24) более быстрое получение данных.

(27) Только для поиска по индексу и то не факт. Но вот места короткие фиксированной длинны будут занимать больше чем длинные переменной.