I’m finding it odd to have these two tables separated, but since there’s no description of the case, you might actually need it. By the name and structure of the tables something tells me you don’t need.
If you want an action in a table to trigger action in another table you need to use triggers. But if there’s only one table You don’t even need this :)
The primary key should never be changed in the database. It doesn’t matter that there will be holes. The only exception is if you create a routine that modifies all references to it throughout the database and can ensure that these keys were not used anywhere outside of DB. But I wouldn’t do that. Practically zero advantages and there are risks.
What you call index is this key, index is a set of keys.
Trying to do what you want will not make the database faster, this is micro-optimization and those that do not bring gains. There’s a chance it could get worse.
To tell the truth in most scenarios I know nothing should be effectively erased unless one has a strategy of how to do this properly.
Even if I wanted to do it, I don’t see the link between one table and another. If it’s the id
then you really don’t need two tables and then the description of the question is wrong.
Model right, create the right indexes, make the right queries, configure the server correctly, make the application the right way and all the architecture of the solution is adequate, make tests, analyze the use, see the bottlenecks, all this is what will make it perform.
simply, don’t do it. Id is the key to that record and should not be changed
– Rovann Linhalis