Subject | Re: [firebird-support] Change table name |
---|---|
Author | Ann W. Harrison |
Post date | 2005-03-05T18:06:27Z |
Kjell Rilbe wrote:
weren't aware of the value of immutable identifiers, or of the general
convenience of using ids (with no case, character set, or collation)
rather than names. Id's are used on internal system tables -
rdb$formats, rdb$pages - that are recreated in a new database. They're
also used to identify data pages, index pages etc.
However, we used a 16 bit id - that seemed pretty generous in 1980, in
terms of the amount of disk space that would use. Even in 1980, we
could imagine that someday, somewhere, somebody might go through all 32K
record ids, and then they'd be stuck. One of the goals of the database
was to allow a backup/restore that tidied up the database, eliminating
holes in the id space, so id's are not immutable across a backup restore.
Regards,
Ann
>Actually, it's not that the original designers of the system tables
>
> Being used to the OO way of thinking, I'd suggest this kind of problem
> to be solved by storing references to named items (tables, indices,
> columns, ...) to be stored as references to object id:s internally. The
> name of an item would then just simply be an attribute of that item.
weren't aware of the value of immutable identifiers, or of the general
convenience of using ids (with no case, character set, or collation)
rather than names. Id's are used on internal system tables -
rdb$formats, rdb$pages - that are recreated in a new database. They're
also used to identify data pages, index pages etc.
However, we used a 16 bit id - that seemed pretty generous in 1980, in
terms of the amount of disk space that would use. Even in 1980, we
could imagine that someday, somewhere, somebody might go through all 32K
record ids, and then they'd be stuck. One of the goals of the database
was to allow a backup/restore that tidied up the database, eliminating
holes in the id space, so id's are not immutable across a backup restore.
Regards,
Ann