на уровне страниц файла базы нет такого понятия, как имена таблиц. Есть только ID.

SwvЗаметил, что для не системных таблиц в начале этого массива идут 4 байта, а потом уже данные полей. Что за 4 байта?
У не системных таблиц перед началом данных полей 8 байт. Что за байты?
определись, о чем именно спрашиваешь. Число байт NULL-маски зависит от числа столбцов таблицы.

SwvВ поле VARCHAR перед данными стоят 2 байта.Что это за байты?
длина строки

SwvВ поле VARCHAR которое NULL стоят 10 байт 0х00.
два байта - длина строки, остальное выравнивание до следующего поля (bigint или double precision, судя по всему)

Тебе надо научиться понимать формат записи (rdb$formats), тогда декодирование записи в отдельные поля становится тривиальным.

еще вот это имеет смысл прочитать, как минимум про NULL-битмапы там разжевано

Dimitry Sibiryakov,

позабыто, наверное. Впрочем, оно мне все равно не нравится. Ибо, во-первых, потребует включать признак nullability столбцов в формат таблицы. А во-вторых, я не вижу чтобы оно дало какой-либо эффект при менее чем 32 ведомых NOT NULL полях (ибо вся экономия сожрется padding-ом до выравнивания первого поля).

Dimitry SibiryakovВо-первых, в формат можно включить уже посчитанную длину маски. Дальше при проверке если поле NULL или нет, будет достаточно ещё одного сравнения его номера с 8*<размер маски из формата>.
Во-вторых, если в таблице два поля и оба NOT NULL - маска будет нулевого размера и в
записи будет сэкономлено 4 байта, поскольку паддинг пойдёт лесом.
В-третьих, это позволит иметь обратно-совместимые внешние файлы с поддержкой NULL-ов, но
это уже отдельный тикет.
1) можно и так. Хотя инкрементировать номер формата (весьма ограниченный ресурс) на каждый чих NULL <-> NOT NULL мне не кажется очень удачной мыслью, даже если это в основном и коснется "таблиц из двух полей".
2) после компрессии экономия будет уже 2 байта
3) IMHO, это единственный повод вообще рассматривать эту идею

Dimitry Sibiryakov,

вот когда этот кто-то (или кто-либо другой) это сделает, тогда и вернемся к этом разговору

SwvВот смотрю я страницу данных RDB$RELATIONS
В таблице 17 полей. Исходя из того, что написано в описании - 4 байта на каждые 32 поля.
И далее кратно 4 байт.
На странице данных по таблице RDB$RELATIONS данных полей начинаются с 9 байта.
т.е. на маску ушло 8.
на маску ушло 4 байта, еще 4 ушло на паддинг для выравнивания (ибо первое поле таблицы - 8-байтный blob id)

SwvИ вопросик по поводу формата записи. Где почитать?
только в исходниках, наверное. В ods.h есть структура Ods::Descriptor. В dsc_offset лежит смещение поля в буфере записи, в dsc_length - длина поля, в dsc_dtype - тип данных и т.п. По rhd_format записи читаешь формат из rdb$formats, там блоб = массиву структур Ods::Descriptor, по одной на поле таблицы.

Swvв RDB$Formats есть записи только на НЕ системные relations.
Как быть с системными?
прошивать их структуру в своей программе. См. /jrd/relations.h, /jrd/ini.epp.

SwvТ.е. если первое поле таблицы BLOB, то будет выравнивание до 8 байт?
да, насколько я помню