ТС_001При текущей структуре хранения это порядка 15ТБ в год на одну БД, а таких БД - 6При таких объемах решение в лоб чисто админское - секционирование (partitioning) и сжатие (compressing) блоков. В зависимости от кластеризации данных, а при секционировании этого можно добиться, эффект от сжатия должен быть хорошим.
Однозначный плюс - не надо переделывать приложение.
Однозначный минус - ваша СУБД (редакция) должна уметь сжимать блоки.

Итак что если опция сжатия недоступна.
Тогда может иметь смысл нормализация (архивирование своими руками) т.е. замена длинного поля короткой ссылкой. Однако боюсь что со строками такой фокус уже был проделан, смысл может быть для дат (если для даты время не нужно, то двухбайтовый день хранящий 64K дней покрывает двести лет). Опять же какая будет выгода зависит от данных.

_мод самое простое: хранить только изменившиеся поля. записей будет много, но на null-ах экономияТеперь по решению обнуления. То есть замены значения алгоритмом - если значение нулл сортируем для данного объекта по дате (или VERSION_ID
) и отступаем на шаг назад пока не получим не нулл значение или пока не кончится курсор.
Тогда ваш запрос на выборку будет типа
если ваша таблица кластеризована по object_id и VERSION_ID (дате) то количество физических чтений будет небольшим, но вот логических чтений будет много.
Можно сделать финт ушами написав фунцию, которая будет в курсоре читать записи по object_id и прекращать фетч когда все поля станут не нулл (реализация сильно зависит от СУБД). Возвращать функция должна несколько значений в одном, типа запись или "в лоб" строку с полями фиксированной ширины. Для того чтобы фетчей было не слишком много надо обнулять не все строки а оставлять периодически записи с заполненными значениями.
Тут может возникнуть проблема отделения null как неизменного значения и null как честного значения в таблице.