On Dec 28, 2004, at 11:44 AM, D.W. wrote:
Is there a function that does what I have described?

[described... 'compact' the primary keys of a database so that there are no unused gaps after a row or rows have been deleted]


No.  And, generally, you really don't want to do that.

The primary keys are generally used to create relationships between tables. That is, the primary key of a row in table A will appear in fields of row or rows in table B (thus called a foreign key).

If you were to go and change the primary keys in table A, it would also require changing all of the foreign keys to A in table B (and all other tables).

This can be significantly expensive and is one of the reasons why it is generally preferable to keep primary keys meaningless beyond being a unique and unchanging row identifier.

If you need a field in table A that acts as a sort of numeric counter of the rows of that table, then create a field to do exactly that and don't use it as a key. in general, I have seen few schemas that actually use such a column of data that requires every number to be consecutive.

If order of insertion is important, most schemas use a creation date column. The database representation is generally an INT containing the number of seconds since some significant date; Jan 1, 1970 or 2000 being the most common. With that, you can always sort on said column to determine insert order and the "index" of a particular row in the overall table can generally be implied by the query itself, though not always.




Reply via email to