Leon wrote:
> And more: would you make a cool data type, a reference,
> which is a physical record number of a foreign record?
> This could make certain type of joins VERY fast, too good
> to be true. Such thing is really an incorporation of
> elements of networking (networked? :) data model into
> relational model.
When you say "a physical record number", I assume you mean some
reference to where the record is stored on disk. There are a number of
problems with this. One is space reclaimation. You can't re-use space
anymore because if you put a new record in the place where the old
record was there would be an integrity problem. If you somehow solve
that there is still the problem that you can't move a record when it
gets bigger or you want to re-organise the database. Backups become
problematic.
In actual fact, you don't need physical record ids to make things
blindingly quick. Object databases like Versant have proved that.
Although I've got no doubt their record-id lookup is massively optimised
for the special case and I'd say it's significantly faster than most
relation database indexes, but the principle is no different. Record ids
are good. Physical record ids are bad.