But, often, when designing a DB, we know in advance the maximum capacity of the table, usually reference tables.
Maybe it makes sense to introduce something like a limitation on the maximum number of records (MaxRecCount) for table metadata and select it from a predefined list when creating a table:
256 -> UInt8
65535 -> UInt16
Default -> UInt32.
I mean that the RecID value is stored in indexes and links, which directly affects the size of index files.
That is, when using the native VDB data storage method, we, winning in the absence of a primary key (which is emphasized in WIKI as a special feature), at the same time lose in size on secondary indexes and links (which is silent about
).Or go the other way - use the method used by SQLite when storing rowid (each row identifier is stored as a variable-length integer, i.e. small rowid values take up less disk space than large rowid values) and try to apply it to storing the RecID value in indexes.
And store the RecID in memory as the same 32 bytes (for simplicity).
Or will such steps not yield significant gains?
