Thanks for all people kindly answering my questions.

Regarding storing blobs in a separate table,
Aage => could be better because that way a page can hold more records
Milan => no need to split blobs into separate table because FB engine is internally doing this job.

Both seem to make sense in one way or another. But I am confused yet.
So, I have read and tried to understand Firebird-internals.pdf. This pdf has a very detail explanation on the database structure to the level of bits. However, unfortunately, it does not have much detail on blobs and is not complete on blobs yet. So I still cannot find an answer whether to separate blobs into a different table or not.

If anyone can clear this issue, that'd be greatly appreciated by all like me.


For your reference, Firebird-internals.pdf' blob part is extracted below (that's all for blob):

Blob Data Page - Type 0x08 - TODO
The C code representation of a blob data page is:
struct blob_page
{
pag blp_header;
SLONG blp_lead_page;
SLONG blp_sequence;
USHORT blp_length;
USHORT blp_pad;
SLONG blp_page[1];
};
Blp_header: The blob page starts off with a standard page header.
Blp_lead_page: Four bytes, signed. Bytes 0x10 - 0x13. This field holds the page number for the first page for
this blob.
Blp_sequence: Four bytes, signed. Bytes 0x14 - 0x17. The sequence number of this page within the page range
for this blob.
Blp_length: Two bytes, unsigned. Bytes 0x18 and 0x19. The length of the blob data on this page, in bytes.
Blp_pad: Two bytes, unsigned. Bytes 0x1a and 0x1b. Not used for any data, used as padding.
Blp_page: This location in the page is at byte 0x1c. It has two purposes:
• An array of four byte, signed page numbers representing all the pages in this blob; or
• An array of bytes making up the blob data on this page.
If the flag byte in the standard page header (pag_flags) is set to 1, this blob page contains no data but acts as a
pointer page to all the other blob pages for this particular blob.


thx all
HR