Qual è un buon modo per reimpostare la chiave primaria?

In base alla mia esperienza, le persone non tecniche spesso pensano che sia corretto riciclare "chiavi" o "ID" dopo un certo periodo di tempo perché "sapremo dalla data in cui era". Non capiscono gli ostacoli tecnici che può causare se si finisce con un computer che cerca di capire quale è quale.

Avere chiavi assolutamente uniche ti dà alcuni grandi vantaggi:

• Puoi creare un indice univoco per essere sempre in grado di trovarlo con il tasto
• Puoi facilmente confrontare se due entità in memoria sono la "stessa" entità (confronta solo le chiavi)
• Rilevamento degli errori: se hai le chiavi duplicate, si tratta di un errore. Fallisci presto.
• Se usi le chiavi sequenziali, viene automaticamente ordinato per la prima volta creato.

Ecco perché preferirei passare a una chiave a 64 bit piuttosto che cercare di riciclare chiavi a 32 bit.

Ora, posso immaginare un sistema in cui potrebbe essere OK per riciclare le chiavi. Se i tuoi dati semplicemente non vivono abbastanza a lungo da avere una chiave duplicata, allora potrebbe andare bene. Sfortunatamente ciò significa che stai progettando te stesso in un angolo. Cosa succede se qualcuno vuole aggiungere una cronologia di audit in seguito? Probabilmente vorranno memorizzare la cronologia di audit per chiave.

Forse sto fraintendendo qualcosa. Se si cambia la chiave a lungo, perché è necessario resettarla a 1.000? Continua ad andare da 2 ^ 32 in poi.

Erano queste soluzioni alternative? È una classe che contiene oggetti che vivono per un tempo molto breve, quindi mentre ha pochissime righe in un particolare momento, agita rapidamente il valore della chiave primaria?

Il riutilizzo è cattivo. Non farlo Causerà più problemi non risolverli Ad esempio, supponiamo di avere un rapporto che è uscito e qualcuno interroga i dati un mese dopo. Se il record è stato rimosso e sostituito da qualcos'altro, allora non capirai di cosa stanno parlando. Se si dispone di un database in cui mancano alcuni vincoli FK (so che non si dovrebbe, ma nel mondo reale accade), si potrebbe improvvisamente avere dati collegati al record sbagliato nelle query. Questo è particolarmente vero dal momento che tu dici che questi dati si diffondono ad altri sistemi e potresti non sapere quale effetto avrebbe su di loro. Rende quasi del 100% probabile che si verifichino effetti molto negativi. Ad esempio, nel fare le importazioni, determiniamo se aggiornare o inserire i dati in base al numero di identificazione del cliente. Se riutilizzi, potresti sovrascrivere le informazioni in modo errato nei loro sistemi (potrebbe non cancellare il vecchio record ma contrassegnarlo come inattivo).

Alcuni sistemi ti permettono di usare numeri negativi come chiave, puoi raddoppiare i numeri disponibili facendo così. C'è anche la possibilità di utilizzare l'ID GUID. Ma personalmente mi piacerebbe passare a Long.

Se decidi di riutilizzare i numeri o di utilizzare Long, devi informare i gestori di ogni altro sistema che potrebbe ottenere dati da te per farglielo sapere. Potrebbe dover apportare modifiche ai loro processi di importazione o segnalazione o alla struttura del database. Abbiamo avuto alcuni problemi di integrità dei dati da risolvere in seguito al cambiamento dei loro id da parte di un cliente senza dircelo.

Dovrai parlare con gli altri tuoi sistemi per esaminare le alternative. Mi aspetterei che passare a un intero a 64 bit sia più probabile che li spezzi.

Suppongo che tu abbia inteso 2 ^ 31 = 2.147.483.647

Sono d'accordo con i suggerimenti fatti finora ...

1-Mai far circolare PK

2-Se si modifica il tipo di dati, è necessario coordinarlo molto bene. Questo non è un cambiamento banale.

C'è qualcosa che potresti voler provare. Per un valore intero vale quanto segue:

-2,147,483,647-1 < = valore intero < = +2,147,483,647

Finora hai usato solo la parte positiva.

Perché non usare la parte negativa? hai ancora circa 2.147.483.647 oggetti da usare senza cambiare il tipo di dati della colonna?