Question

I wondered if I insert, let’s say, 10 entries into a SQL Server table.
If i then delete one of them, will the id/index change correspondingly?

Example:

1 | Simon Cowell | 56 years
2 | Frank Lampard| 24 years
3 | Harry Bennet | 12 years

If I delete #2, will Harry Bennet’s index change to 2?

Thanks 🙂

EDIT:
Sorry for my outrage, had a bad day. And yes, I should have researched it myself, I deserve to be downvoted.
I don’t ask for anything, I just want to say that I’m sorry 😐

Answer 1

Since you seem to be conflating “id/index” let’s talk a little but about the primary key and indexes in the context of a relational database.

The “id” or primary key assigned to a row in a SQL database is the unique identifier for that row. It can consist of one or more columns. (When more than one column is involved it is known as a “composite” or “multi-part” key.) The primary key should really do nothing more than be a unique handle for addressing a row: the primary key should not contain any information about the entity represented by the row, especially if that info has the potential to be mutable; an example would be a part number that has a suffix that stands for the type of metal the part is made from; if that metal can possibly change from titanium to unobtainium, say, that part number would make a bad choice as a primary key; it would be better to have another column to store the type of metal than to make the metal-type suffix part of the primary key. “Meaningful” primary keys might have made some sense in legacy non-relational databases but in a relational database they are to be avoided.

When seeking to enforce the uniqueness of a primary key, a database engine can make use of an index so it can rapidly test whether the key value exists. It could use a binary algorithm to find the value, avoiding the need to scan the actual data “brute force”, row by row, looking for the value. But the index that is used behind the scenes by the engine to assist it with the primary key housekeeping is not the same as the primary key itself.

If you have a simple sequential integer as your primary key, there’s an infinite number of them, so there is no need to reuse an integer when it becomes available when the row to which it was assigned has been deleted. So the relational database engine won’t automatically attempt to reuse it, and it won’t by any means change the primary key values that have been assigned to all other rows in the table when “gaps” in the number sequence are created by a deletion. Many other rows in other tables could be referencing those values and having them be mutable would create either chaos or a huge inefficiency.

Hashing algorithms are another very efficient way a database engine can quickly test for the existence of a key value. It computes the location in the hashed-file where the key would be if it did exist, and then looks there for it. The rows are stored in no particular order, so such schemes are optimized for instant finding of records in a large table, not for culling records that have a common characteristic, such as all customers in zipcode 10023.