Re-seed della colonna Identity: quando è necessario?

Durante una delle ultime lezioni all'università (sono uno studente), il docente ci ha chiesto di sviluppare un database (MySQL Server se è importante) e una piccola app client che consumerebbe il database come fonte di dati.

Uno dei requisiti era che la colonna identità (che è la PK in ogni tabella) deve essere sequenziale, perché è una buona pratica (come da parole del docente). Cioè, quando la riga della tabella viene eliminata, è necessario riutilizzare PK nei successivi inserimenti. Ho una conoscenza media di RDBMS, PK e colonne di identità. Da quello che ho capito, quella colonna di identità è solo un modo per consentire a DB di generare automaticamente PK quando si inseriscono righe e nient'altro. E il valore della colonna identità non deve essere in alcun modo correlato agli attributi di riga (purché non sia una chiave naturale).

Questo requisito (colonna di identità strettamente sequenziale) era sospetto per me. Ho cercato di chiedere al docente cosa c'è di sbagliato se l'identità non è sequenziale (con lacune causate da eliminazioni), ma ho ottenuto una risposta molto astratta come "è conveniente per gli utenti e utile per gli amministratori di database che gestiscono il database". Nessun esempio specifico. L'argomento "conveniente per gli utenti" sembra sciocco, perché non ha alcun significato nel dominio aziendale.

Quindi sono curioso di sapere se questi motivi sono reali? Posso pensare solo a un caso in cui è richiesto il ridimensionamento della colonna identità - quando lo spazio identità è esaurito. Ma questo è un altro problema di progettazione quando il tipo di colonna di identità è stato scelto in modo errato, diciamo semplice intanziché biginto uniqueidentifierquando la tabella contiene miliardi di righe. Supponiamo che una colonna di identità sia un indice cluster: le lacune nella colonna di identità possono influire sulle prestazioni dell'indice? Forse ci sono altri motivi reali per il re-seed automatico della colonna di identità dopo ogni eliminazione di cui non sono a conoscenza?

Grazie in anticipo!

Cioè, quando la riga della tabella viene eliminata, è necessario riutilizzare PK nei successivi inserimenti.

Da quale universo è il tuo conferenziere ??

Questo è gravemente inefficiente. Se provi a farlo, ridurrai le tue prospettive di performance di un fattore 10.

Se sono necessari numeri gapless per motivi di controllo, crearli esplicitamente, non direttamente dagli strumenti del database. E non eliminare mai le righe, ma contrassegnarle come "eliminate". Ciò aumenterà il disordine delle query, poiché dovranno ignorare tali righe.

In MySQL, InnoDB richiede l'esistenza di un unico PRIMARY KEYper ogni tabella. Ma questa è l'estensione del requisito. La chiave può anche essere una stringa.

Le lacune sono una comodità per gli utenti e i DBA, non un inconveniente.

Mi viene in mente un caso in cui il gapless sarebbe conveniente: la suddivisione in gruppi di 100 file alla volta. Ma c'è una semplice soluzione usando LIMIT 100,1.

Le lacune non hanno alcun impatto sulle prestazioni. Ciò include indici non numerici. E indici non univoci. E indici compositi.

Certo, puoi rimanere senza ID. Penso di averlo visto accadere due volte in quasi 2 decenni di utilizzo di MySQL. Potrei anche preoccuparmi di essere colpito da un asteroide. È in basso nella mia lista di cose che mi tengono sveglio la notte.

Subisca interruzioni da (almeno): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(esplicita, oa causa di crash), la replica multi-master (tra cui Galera e gruppo di replica). Vuoi davvero trovare soluzioni alternative per quelli ?!

Sentiti libero di farci controllare dal punto di vista sanitario qualsiasi altra cosa che il docente afferma sia sospetta.

Il riutilizzo di un valore di identità, in generale, dovrebbe essere scoraggiato. O il valore viene utilizzato interamente internamente, nel qual caso il suo valore effettivo è irrilevante, oppure viene utilizzato anche esternamente, nel qual caso il riutilizzo del valore porterà molto probabilmente a un'identificazione errata.

Prendi il caso ovvio di una fattura o di un numero di ordine di acquisto, questi potrebbero facilmente provenire da una colonna di identità ed essere esposti esternamente, ma non vorrai mai riutilizzarli proprio per questo motivo. Entrambi si riferiscono a transazioni specifiche che non si desidera confondere.

Risolvere tali problemi può essere una seccatura quando le aziende si uniscono o vengono acquisite. Creare tali problemi di proposito? Non saggio.

Il riutilizzo dei valori ID PK ha problemi e generalmente dovrebbe essere evitato.

Innanzitutto, l'implementazione delle colonne auto_increment non fornisce la garanzia di essere gapless. In effetti si verificheranno lacune se si esegue il rollback di un inserimento su una colonna di incremento automatico.

In secondo luogo, l'ID gap può riferirsi a dati esistenti che non sono stati eliminati (a causa di vincoli FK mancanti). Se si traducono in numeri di membri comunicati all'esterno del sistema, ciò comporta potenziali rischi di identità aziendale.

In terzo luogo, bigint unsignednon rimarrà a corto di ID per un periodo di tempo significativo, anche a causa di una velocità di inserimento estremamente elevata.

Il più grande dolore con le lacune sta incontrando i revisori che insistono che è un difetto di revisione. Per i DBA sanno che esistono lacune e perché.

Non farò eco ai commenti di tutti che il riutilizzo di un PK sia una cattiva idea, ma mi sono imbattuto in momenti in cui una colonna identità doveva essere riprogrammata.

Corruzione dell'indice PK stesso.

Concesso che utilizzava MS-SQL e molti, molti anni fa, ma è ancora rilevante. Molti anni fa per l'azienda per la quale lavoro, qualcuno ha pensato che sarebbe stata una buona idea riutilizzare i PC come server nelle nostre oltre 150 sedi remote dopo che erano troppo vecchi per essere utilizzati dai client e poi metterli in un armadio senza ventilazione. Quando no Perché sappiamo tutti che un mucchio di computer spazzatura di 10 anni in una piccola stanza con temperature di oltre 120 database in esecuzione mission-critical potrebbe solo portare a cose buone. Come il 40% dei tassi di fallimento e io sto ripensando la mia scelta di carriera. Vorremmo replicare i dati nella sede centrale del corpo, ma il più delle volte questi errori comporterebbero cose brutte che accadono ai database. Una di queste cose era il database con indici danneggiati che avrebbero sequestrato il database e il processo di replica. Due volte in questo fantastico ambiente, l'unica soluzione per correggere la replica era ridimensionare gli indici e ristabilire la replica. In seguito abbiamo sostituito i server prima di abbandonarli completamente.