miksoftДопустим, есть сжатый по zip-образномуалгоритму логический блок таблицы. Он размещается целиком в физическом блоке меньшего размера.

это ужасно. Надеюсь что нет таких СУБД, которые сжимают целиком содержимое "блоков" или страниц.
Давайте лучше рассмотрим разные варианты сжатия, которые имеются, последовательно, от отсутствия сжатия до например того, что мне известно о Firebird.

Итак, если ничего не сжимается:
- записи хранятся полной длины. Например, если есть столбец varchar(1024), то так на диске 1к и хранится, независимо от содержимого.
- ключи хранятся тоже по полной длине, причем даже есть два рядом одинаковых ключа, они так и хранятся - ключ+ссылка на запись.

Теперь, варианты сжатия ключей , последовательно:
1 . не хранить концевые пробелы для строк, или записывать кол-во концевых пробелов. Для чисел - убирать "лишние" нули.

2 . префиксное сжатие следующего ключа на основании значения предыдущего. Например, есть ключи "Иванов и "Иванова". При сжатии во втором ключе мы напишем "6а"

3 . для одинаковых ключей вообще их не хранить, а формировать список номеров записей для конкретного ключа. Например есть
Иванов 50
Иванов 55
вместо этого записать ключ Иванов и к нему 2 ссылки на записи 50 и 55.

в ФБ используются все 3 способа. Описание есть в статье
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert1

реальный пример:
таблица с 2189152 записей integer. Индекс первичного ключа занимает 12.63 мегабайт а, средняя длина ключа равна 1 байту. Если ничего не сжимать, и взять размер ключа по минимуму - 4 байта значение (integer) и 8 байт ссылка на запись, то такой теоретический индекс занимал бы 25 мегабайт (с тем же числом ключей). Замечу, что это УНИКАЛЬНЫЙ индекс, где ключи не повторяются. Но зато они упаковываются потому, что числа обычно идут подряд :-)

В этой же таблице индекс по GUID varchar(16), заполненный одним (!) значением занимает 8.38 мегабайт. Тут "упаковка" максимальная, т.к. на самом деле ключ один, и 2 миллиона ссылок на записи. (индекс бесполезный, кстати).

могу еще практические примеры привести, у меня их навалом.

Теперь сжатие записей :
1. у строк не хранить концевые пробелы или записывать кол-во концевых пробелов. То есть запись получается переменной длины.

реальный пример - в таблице из столбцов vchar(32), vchar(32), char(1), vchar(64), vchar(512) при максимально возможном размере записи в 649 байт средний размер записи - 169 байт.
Или, таблица с примерно 20-ю столбцами и макс. размером записи в 868 байт на деле имеет средний размер записи 124 байта.
Понятно что это данные по конкретной БД и конкретным таблицам, но в среднем в IB/FB реальные данные на диске занимают примерно в 3 раза меньше чем посчитанная по размеру полей структура таблицы.

2. тут лучше пусть hvlad допишет :-)

я же добавлю еще ссылку на структуру страниц ФБ:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert2

MasterZivЭто всё я бы не подразумевал под "сжатием данных". Это -- детский
сад, приёмы, которые используют все более-менее современные СУБД.
Это не интересно.
гм. а на мой взгляд "нефиксированный" размер записи - это уже сжатие, я результат привел. По поводу "все более-менее" - мы уже в курсе что Оракл как-то сжимает, но у него это по умолчанию отключено.

Посмотрите у себя размер уникального индекса по integer. я дал пример для ФБ что сжатие примерно 0.64 (именно для уникального). Давайте сравним.