Три таблицы (CAULDRON, CAULDRON1 и CAULDRON2) имеют одинаковые метаданные и объем 100 000 записей. Номинальная, несжатая длина записи 900 байт.

CAULDRON - чистая таблица без старых версий строк. Средняя длина хранимой строки 121 байт - приблизительно 87% сжатия.

CAULDRON1 имеет активную, все еще выполняющуюся транзакцию:

DELETE FROM CAULDRON1;

Каждая строка имеет нулевую (0.00) длину, потому что первичная запись является заглушкой удаления (delete stub), которая содержит только заголовок строки. Все подтвержденные записи были восстановлены как старые версии и сжаты до того же размера, который они имели, когда были первичными записями. Таблица содержит то же количество страниц (4000), что и до операции DELETE. Средний коэффициент заполнения составляет от 85 до 95% для размещения всех заглушек удаления.

CAULDRON2 имеет активную, все еще выполняющуюся транзакцию:

UPDATE CAULDRON2 SET F20FFSET = 5.0

Измененные записи увеличили размер на 2 байта (с 121 до 123), что можно отнести к более низкому уровню сжатия.

Значение 5.0 заменило большинство отсутствующих или нулевых значений, что сделало значение этого поля отличным от других полей. Теперь существует 100 000 старых версий со средним значением 10 байт каждая. Средний коэффициент заполнения увеличен до 99%, а таблица выросла с 138 до 4138 страниц.

> gstat proj.gdb -r -t CAULDRON CAULDRONI CAULDRON2

. . .

Analyzing database pages . . .

CAULDRON (147)

Primary pointer page: 259, Index root page: 260

Average record length: 120.97, total records: 100000

Average version length: 0.00, total versions: 0, max versions: 0

Data pages: 4000, data page slots: 4000, average fill: 85%

Fill distribution:

0 -19%=0

20 -39%=0

40 -59%=0

60 -79%=0

80 -99%=4000

CAULDR0N1 (148)

Primary pointer page: 265, Index root page: 266

Average record length: 0.00, total records: 100000

Average version length: 120.97, total versions: 100000, max versions: 1

Data pages: 4000, data page slots: 4000, average fill: 95%

Fill distribution:

0 -19%=0

20 -39%=0

40 -59%=0

60 -79%=0

80 -99%=4000

CAOLDRON2 (149)

Primary pointer page: 271, Index root page: 272

Average record length: 122.97, total records: 100000

Average version length: 10.00, total versions: 100000, max versions: 1

Data pages: 4138, data page slots: 4138, average fill: 99%

Fill distribution:

0 -19%=0

20 -39%=0

40 -59%=0

60 -79%=0

80 -99%=4138

! ! !

СОВЕТ. Для API-программистов функция API Firebird isc_database_info и Services API предоставляют элементы, которые делают возможным синхронизировать выполнение поиска и получение статистики по базе данных в ваших программах приложений. Для программистов Delphi, C++ Builder и Kylix доступны различные наборы компонентов для получения статистики базы данных.

. ! .

Здесь мы завершаем обсуждение объектов базы данных и перемещаем фокус на язык создания и изменения данных. Наше исследование начинается с общего взгляда на SQL в терминах стандартов и как реализация Firebird разбивается на множество перекрывающихся подмножеств. После этого в главе 20 мы начинаем более подробное рассмотрение данных как множеств и операторов языка манипулирования данными (Data Manipulation Language, DML) для определения данных и манипуляций с ними.

SQL (произносится "эс кю эль" [62] ) - это подъязык данных для доступа к реляционным системам управления базами данных. Его элементы, синтаксис и поведение стандартизовали ANSI и ISO в 1986 году.

С этого времени SQL пересматривался три раза: SQL-89 (опубликован в 1989 г.), SQL-92 (1992 г. или около этого) и самый последний SQL 3, рабочая версия, опубликованная как часть SQL-99.

Язык запросов стандарта SQL является непроцедурным языком, т. е. он ориентирован на результаты операций, а не на способы получения результатов. Его назначение - быть основой для подъязыка, используемого в рамках включающего языка программирования. Цель стандартов - описать механизм внешнего уровня, посредством которого заданный запрос вернет предсказуемый результат, независимо от того, как сервер базы данных внутренне манипулирует данными.

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