È buona norma disporre sempre di una chiave primaria intera con incremento automatico?

Nei miei database, tendo a prendere l'abitudine di avere una chiave primaria intera a incremento automatico con il nome id per ogni tabella che creo in modo da avere una ricerca univoca per ogni riga particolare.

È considerata una cattiva idea? Ci sono degli svantaggi nel farlo in questo modo? A volte avrò più indici come id, profile_id, subscriptionsdove si idtrova l'identificatore univoco, i profile_idcollegamenti allo straniero iddi aProfile tabella, ecc.

O ci sono scenari in cui non si desidera aggiungere un tale campo?

Non è mai una cattiva idea avere un identificatore di riga univoco garantito. Immagino che non dovrei dire mai - ma andiamo con la stragrande maggioranza delle volte è una buona idea.

I potenziali svantaggi teorici includono un indice aggiuntivo da mantenere e uno spazio di archiviazione aggiuntivo utilizzato. Per me non è mai stato un motivo sufficiente per non usarne uno.

Non sono d'accordo con tutte le risposte prima. Ci sono molti motivi per cui è una cattiva idea aggiungere un campo di incremento automatico in tutte le tabelle.

Se hai una tabella in cui non ci sono chiavi ovvie, un campo di incremento automatico sembra una buona idea. Dopo tutto, non vuoi select * from blog where body = '[10000 character string]'. Preferirestiselect * from blog where id = 42 . Direi che nella maggior parte di questi casi, ciò che vuoi davvero è un identificatore univoco; non un identificatore univoco sequenziale. Probabilmente si desidera utilizzare invece un identificatore univoco universale.

Ci sono funzioni nella maggior parte dei database per generare identificatori univoci casuali ( uuidin mysql, postgres.newid In mssql). Ciò consente di generare dati in più database, su macchine diverse, in qualsiasi momento, senza alcuna connessione di rete tra loro, e di unire ancora i dati con zero conflitti. Ciò consente di configurare più facilmente server multipli e persino data center, come ad esempio con microservizi.

Questo evita anche che gli aggressori indovinino gli URL alle pagine a cui non dovrebbero avere accesso. Se c'è un https://example.com/user/1263probabilmente c'è un https://example.com/user/1262 . Ciò potrebbe consentire l'automazione di un exploit di sicurezza nella pagina del profilo utente.

Ci sono anche molti casi in cui una colonna uuid è inutile o addirittura dannosa. Diciamo che hai un social network. C'è un userstavolo e un friendstavolo. La tabella degli amici contiene due colonne userid e un campo di incremento automatico. Vuoi 3essere amico di 5, quindi inseriscilo 3,5nel database. Il database aggiunge un ID di incremento automatico e memorizza 1,3,5. In qualche modo, l'utente fa di nuovo 3clic sul pulsante "Aggiungi amico". Si inserisce 3,5nuovamente nel database, il database aggiunge un ID di incremento automatico e inserisce 2,3,5. Ma ora 3e 5siamo amici l'uno con l'altro due volte! Questo è uno spreco di spazio, e se ci pensate, lo è anche la colonna di auto-incremento. Tutto ciò che serve per vedere se aebsono amici è selezionare per la riga con questi due valori. Sono, insieme, un identificatore di riga univoco. (Probabilmente vorrai scrivere qualche logica per assicurarti 3,5e 5,3sono deduplicati.)

Ci sono ancora casi in cui gli ID sequenziali possono essere utili, come quando si costruisce un accorciatore di url, ma soprattutto (e anche con l'accorciatore di url) un ID univoco generato casualmente è ciò che si desidera realmente utilizzare.

TL; DR: utilizzare gli UUID anziché l'auto-incremento, se non si dispone già di un modo univoco per identificare ciascuna riga.

Le chiavi autoincementali presentano principalmente vantaggi.

Ma alcuni possibili inconvenienti potrebbero essere:

• Se si dispone di una chiave aziendale, è necessario aggiungere un indice univoco anche su quella colonna / e per applicare le regole aziendali.
• Quando si trasferiscono dati tra due database, in particolare quando i dati si trovano in più di una tabella (ovvero master / dettaglio), non è semplice poiché le sequenze non sono sincronizzate tra i database e sarà necessario creare prima una tabella di equivalenza utilizzando chiave di business come corrispondenza per sapere quale ID del database di origine corrisponde a quale ID nel database di destinazione. Tuttavia, ciò non dovrebbe costituire un problema durante il trasferimento di dati da / a tabelle isolate.
• Molte aziende dispongono di strumenti di reporting ad hoc, grafici, point-and-click, drag-and-drop. Poiché gli ID autoincrementali non hanno senso, questo tipo di utenti troverà difficile dare un senso ai dati al di fuori di "l'app".
• Se modifichi accidentalmente la chiave aziendale, è probabile che non recupererai mai quella riga perché non hai più qualcosa che gli umani possano identificarla. Ciò ha causato un errore nella piattaforma BitCoin una volta .
• Alcuni designer aggiungono un ID a una tabella di join tra due tabelle, quando il PK dovrebbe essere semplicemente composto da due ID esterni. Ovviamente se la tabella di join si trova tra tre o più tabelle, allora ha senso un ID autoincrementale, ma è necessario aggiungere una chiave univoca quando si applica alla combinazione di FK per far rispettare le regole aziendali.

Ecco una sezione dell'articolo di Wikipedia sugli svantaggi delle chiavi surrogate.

Per essere al contrario, No, NON è necessario disporre sempre di un AutoKc numerico.

Se analizzi attentamente i tuoi dati, spesso identifichi le chiavi naturali nei dati. Questo è spesso il caso in cui i dati hanno un significato intrinseco per l'azienda. A volte i PK sono artefatti di sistemi antichi che gli utenti aziendali utilizzano come seconda lingua per descrivere gli attributi del loro sistema. Per esempio, ho visto i numeri VIN del veicolo utilizzati come chiave primaria di una tabella "Veicolo" in un sistema di gestione della flotta.

Comunque abbia avuto origine, SE hai già un identificatore univoco, usalo. Non creare una seconda chiave primaria insignificante; è dispendioso e può causare errori.

A volte è possibile utilizzare un PK AutoInc per generare un valore significativo per il cliente, ad esempio Numeri di polizza. Impostare il valore iniziale su qualcosa di sensato e applicare le regole di business sui principali zeri ecc. Questo è probabilmente un approccio "migliore di entrambi i mondi".

Quando si dispone di un numero limitato di valori relativamente statici, utilizzare i valori che hanno senso per l'utente del sistema. Perché utilizzare 1,2,3 quando è possibile utilizzare L, C, H dove L, H e C rappresentano la vita, l'auto e la casa in un contesto di "tipo di polizza" assicurativo o, tornando all'esempio VIN, che ne dici di usare "TO "per Toyota? Tutte le auto Toyata hanno un VIN che inizia con "TO" È una cosa in meno che gli utenti devono ricordare, rende meno probabile l'introduzione di errori di programmazione e degli utenti e può anche essere un surrogato utilizzabile per una descrizione completa nei report di gestione che semplifica i report da scrivere e forse più veloce da generare.

Un ulteriore sviluppo di questo è probabilmente "un ponte troppo lontano" e generalmente non lo consiglio, ma lo sto includendo per completezza e potresti trovare un buon uso per questo. Cioè, utilizzare la descrizione come chiave primaria. Per i dati che cambiano rapidamente questo è un abominio. Per dati molto statici riportati su All The Time , forse no. Ne ho appena parlato, quindi è seduto lì come una possibilità.

Faccio uso di AutoInc PK, mi impegno solo il cervello e cerco prima alternative migliori. L'arte della progettazione di database sta facendo qualcosa di significativo che può essere interrogato rapidamente. Avere troppi join impedisce questo.

MODIFICA Un altro caso cruciale in cui non è necessario un PK autogenerato è il caso di tabelle che rappresentano l'intersezione di altre due tabelle. Per attenersi all'analogia di Car, A Car ha 0..n accessori, ogni accessorio può essere trovato su molte auto. Quindi, per rappresentarlo, crei una tabella Car_Accessory contenente i PK di auto e accessori e altre informazioni rilevanti sulle date del link, ecc.

Ciò di cui non hai bisogno (di solito) è un PK AutoInc su questa tabella: si accederà solo tramite l'auto "dimmi quali accessori ci sono su questa auto" o dall'Accessorio "dimmi quali auto hanno questo accessorio"

Molti tavoli hanno già un ID unico naturale. Non aggiungere un'altra colonna ID univoca (incremento automatico o altro) a queste tabelle. Utilizzare invece l'id unico naturale. Se aggiungi un altro ID univoco, essenzialmente hai una ridondanza (duplicazione o dipendenza) nei tuoi dati. Questo va contro i principi della normalizzazione. Un ID univoco dipende dall'altro per la precisione. Ciò significa che devono essere perfettamente sincronizzati in ogni momento in ogni sistema che gestisce queste righe. È solo un'altra fragilità nell'integrità dei dati che non vuoi davvero gestire e convalidare a lungo termine.

La maggior parte delle tabelle al giorno d'oggi non ha davvero bisogno del potenziamento delle prestazioni molto minore che darebbe una colonna id univoca aggiuntiva (e talvolta riduce anche le prestazioni). Come regola generale nell'IT, evitare la ridondanza come la peste! Resistilo ovunque ti venga suggerito. È un anatema. E attenzione alla citazione. Tutto dovrebbe essere il più semplice possibile, ma non più semplice. Non avere due ID univoci in cui uno sarà sufficiente, anche se quello naturale sembra meno ordinato.

Sui sistemi più grandi, ID è un booster di coerenza, usalo quasi ovunque. In questo contesto, le singole chiavi primarie NON sono raccomandate, sono costose nella linea di fondo (leggi perché).

Ogni regola ha un'eccezione, quindi potrebbe non essere necessario l'ID di incremento automatico intero sulle tabelle di gestione temporanea utilizzate per l'esportazione / importazione e su tabelle unidirezionali simili o tabelle temporanee. Preferiresti anche i GUID invece degli ID sui sistemi distribuiti.

Molte risposte qui suggeriscono che dovrebbe essere presa la chiave unica esistente. Bene anche se ha 150 caratteri? Io non la penso così.

Ora il mio punto principale:

Sembra che gli oppositori dell'ID intero di autoincremento stiano parlando di piccoli database con un massimo di 20 tabelle. Lì possono permettersi un approccio individuale a ciascun tavolo.

MA una volta che hai un ERP con oltre 400 tabelle, con ID di incremento automatico intero ovunque (tranne i casi menzionati sopra) ha molto senso. Non si fa affidamento su altri campi univoci anche se sono presenti e protetti per unicità.

• Approfittate di convenzioni universali per risparmiare tempo, risparmiare sforzo e facili da ricordare.
• Nella maggior parte dei casi JOINtabelle, senza bisogno di controllare quali sono le chiavi.
• Puoi avere routine di codice universali che funzionano con la colonna di incremento automatico dei numeri interi.
• È possibile estendere il sistema con nuove tabelle o plug-in utente non previsti prima semplicemente facendo riferimento agli ID delle tabelle esistenti. Sono già lì dall'inizio, senza costi aggiuntivi per aggiungerli.

Sui sistemi più grandi, può valere la pena ignorare i vantaggi minori di quelle singole chiavi primarie e utilizzare costantemente l'ID di incremento automatico intero nella maggior parte dei casi. L'uso di campi univoci esistenti come chiavi primarie sta forse salvando alcuni byte per record, ma i tempi di archiviazione o indicizzazione aggiuntivi non rappresentano un problema nei motori di database di oggi. In realtà stai perdendo molto più denaro e risorse sul tempo perso dagli sviluppatori / manutentori. Il software di oggi dovrebbe essere ottimizzato per il tempo e lo sforzo dei programmatori: quale approccio con ID coerenti soddisfa molto meglio.

Non è buona pratica progettare in modo superfluo. Vale a dire - non è buona norma disporre sempre di una chiave primaria di incremento automatico quando non è necessaria.

Vediamo un esempio in cui non è necessario.

Hai una tabella per gli articoli: questa ha una chiave primaria int ide una colonna varchar denominata title.

Hai anche una tabella piena di categorie di articoli - in idchiave primaria, varchar name.

Una riga nella tabella Articoli ha un numero iddi 5 e un title "Come cucinare l'oca con il burro". Desideri collegare l'articolo con le seguenti righe nella tabella Categorie: "Fowl" ( id : 20), "Goose" ( id : 12), "Cooking" ( id : 2), "Butter" (id: 9) .

Ora hai 2 tabelle: articoli e categorie. Come si crea la relazione tra i due?

Potresti avere una tabella con 3 colonne: id (chiave primaria), article_id (chiave esterna), category_id (chiave esterna). Ma ora hai qualcosa del tipo:

| id | a_id | c_id |
| 1 | 5 | 20 |
| 2 | 5 | 12 |
| 3 | 5 | 2 |

Una soluzione migliore è avere una chiave primaria composta da 2 colonne.

| a_id | c_id |
| 5 | 20 |
| 5 | 12 |
| 5 | 2 |

Questo può essere realizzato facendo:

create table articles_categories (
  article_id bigint,
  category_id bigint,
  primary key (article_id, category_id)
) engine=InnoDB;

Un altro motivo per non utilizzare un numero intero con incremento automatico è se si utilizzano UUID per la chiave primaria.

Gli UUID sono, per definizione, unici, il che compie la stessa cosa che usa gli interi univoci. Hanno anche i loro vantaggi (e contro) aggiuntivi rispetto agli interi. Ad esempio, con un UUID, sai che la stringa univoca a cui ti riferisci punta a un particolare set di dati; questo è utile nei casi in cui non si dispone di 1 database centrale o in cui le applicazioni hanno la possibilità di creare record di dati offline (quindi caricarli nel database in un secondo momento).

Alla fine, non devi pensare alle chiavi primarie come una cosa. Devi pensare a loro come alla funzione che svolgono. Perché hai bisogno delle chiavi primarie? Essere in grado di identificare in modo univoco insiemi di dati specifici da una tabella utilizzando un campo che non verrà modificato in futuro. Hai bisogno di una colonna specifica chiamata idper fare questo, o puoi basare questa identificazione univoca su altri dati (immutabili)?

O ci sono scenari in cui non si desidera aggiungere un tale campo?

Sicuro.

Prima di tutto, ci sono database che non hanno autoincrementi (ad esempio Oracle, che certamente non è uno dei contendenti più piccoli in circolazione). Questa dovrebbe essere una prima indicazione del fatto che non a tutti piacciono o ne hanno bisogno.

Ancora più importante, pensa a cosa sia effettivamente l'ID : è una chiave primaria per i tuoi dati. Se hai una tabella con una chiave primaria diversa, non hai bisogno di un ID e non dovresti averne una. Ad esempio, una tabella (EMPLOYEE_ID, TEAM_ID)(in cui ciascun dipendente può far parte di più team contemporaneamente) ha una chiave primaria chiaramente definita costituita da quei due ID. L'aggiunta di una IDcolonna di incremento automatico , che è anche una chiave primaria per questa tabella, non avrebbe alcun senso. Ora stai trascinando in giro 2 chiavi primarie e la prima parola in "chiave primaria" dovrebbe darti un suggerimento che dovresti davvero averne solo una.

Di solito utilizzo una colonna "identità" (numero intero auto-incremennante) quando definisco nuove tabelle per dati "di lunga durata" (record che prevedo di inserire una volta e di conservare a tempo indeterminato anche se finiscono per "logicamente cancellati" impostando un campo bit ).

Ci sono alcune situazioni a cui riesco a pensare quando non vuoi usarle, la maggior parte delle quali si riducono a scenari in cui una tabella su un'istanza del DB non può essere la fonte autorevole per i nuovi valori ID:

• Quando gli ID incrementali sarebbero troppe informazioni per un potenziale attaccante. L'uso di una colonna di identità per servizi di dati "rivolti al pubblico" ti rende vulnerabile al "problema dei carri armati tedeschi"; se esiste l'ID record 10234, è logico che esista il record 10233, 10232, ecc., almeno al record 10001, quindi è facile controllare i record 1001, 101 e 1 per capire dove è iniziata la colonna identità. I GUID V4 composti principalmente da dati casuali interrompono questo comportamento incrementale in base alla progettazione, quindi solo perché esiste un GUID, non esiste necessariamente un GUID creato aumentando o decrementando un byte del GUID, rendendo più difficile per un utente malintenzionato utilizzare un servizio indotto per il recupero di un singolo record come strumento di dump. Esistono altre misure di sicurezza che possono limitare meglio l'accesso, ma questo aiuta.
• In M: M tabelle di riferimento incrociato. Questo è un tipo di dammi ma l'ho già visto fare prima. Se si dispone di una relazione molti-a-molti tra due tabelle nel database, la soluzione di riferimento è una tabella con riferimenti incrociati contenente colonne di chiavi esterne che fanno riferimento al PK di ciascuna tabella. Il PK di questa tabella dovrebbe essere virtualmente sempre una chiave composta delle due chiavi esterne, per ottenere il comportamento dell'indice incorporato e garantire l'univocità dei riferimenti.
• Quando prevedi di inserire e cancellare in blocco su questa tabella molto. Probabilmente il più grande svantaggio delle colonne di identità è l'hoopla extra che devi affrontare quando esegui un inserimento di righe da un'altra tabella o query, in cui desideri mantenere i valori chiave della tabella originale. Devi attivare "inserimento identità" (comunque nel tuo DBMS), quindi assicurarti manualmente che le chiavi che stai inserendo siano univoche, quindi quando hai finito con l'importazione devi impostare il contatore identità nel i metadati della tabella al massimo valore presente. Se questa operazione si verifica molto su questa tabella, prendere in considerazione uno schema PK diverso.
• Per tavoli distribuiti.Le colonne di identità funzionano perfettamente per database a istanza singola, coppie di failover e altri scenari in cui un'istanza di database è l'unica autorità sull'intero schema dati in qualsiasi momento. Tuttavia, c'è solo così grande che puoi andare e avere un computer abbastanza veloce. La replica o la distribuzione dei registri delle transazioni possono procurarti copie di sola lettura aggiuntive, ma esiste anche un limite alla scala di tale soluzione. Prima o poi avrai bisogno di due o più istanze del server che gestiscono gli inserti di dati e poi si sincronizzano tra loro. Quando si verifica tale situazione, è necessario un campo GUID anziché uno incrementale, poiché la maggior parte dei DBMS viene preconfigurata per utilizzare una parte dei GUID generati come identificatore specifico dell'istanza, quindi generare il resto dell'identificatore in modo casuale o in modo incrementale. In ogni caso,
• Quando è necessario applicare l'univocità su più tabelle nel DB.È comune nei sistemi contabili, ad esempio, gestire la contabilità generale (con una riga per ogni credito o debito di ogni conto che si è mai verificato, quindi diventa molto grande molto rapidamente) come una sequenza di tabelle che rappresentano ciascuna un mese di calendario / anno. È quindi possibile creare viste per collegarle insieme ai report. Logicamente, questa è tutta una tabella molto grande, ma troncarla semplifica i lavori di manutenzione del DB. Tuttavia, presenta il problema di come gestire gli inserti in più tabelle (consentendo di iniziare a registrare le transazioni nel mese successivo pur chiudendo l'ultimo) senza finire con chiavi duplicate. Ancora una volta, i GUID invece delle colonne di numeri interi di identità sono la soluzione ideale, poiché il DBMS è progettato per generarli in un modo davvero unico,

Esistono soluzioni alternative che consentono l'uso delle colonne di identità in queste situazioni, come ho sperato di aver menzionato, ma nella maggior parte di questi, l'aggiornamento dalla colonna di numeri interi di identità a un GUID è più semplice e risolve il problema in modo più completo.

Una chiave primaria auto-incrementata (identità) è una buona idea se non per notare che è priva di significato al di fuori del contesto del database e dei client immediati di quel database. Ad esempio, se trasferisci e memorizzi alcuni dei dati in un altro database, quindi procedi a scrivere dati diversi su entrambe le tabelle del database, gli ID divergeranno, ovvero i dati con un ID di 42 in un database non corrisponderanno necessariamente ai dati con un ID di 42 nell'altro.

Detto questo, se è necessario essere ancora in grado di identificare le righe in modo univoco al di fuori del database (e spesso lo è), è necessario disporre di una chiave diversa per questo scopo. Una chiave aziendale attentamente selezionata farà, ma spesso finirai nella posizione di un gran numero di colonne necessarie per garantire l'univocità. Un'altra tecnica consiste nell'avere una colonna Id come chiave primaria cluster con incremento automatico e un'altra colonna uniqueidentifier (guid) come chiave univoca non cluster, allo scopo di identificare in modo univoco la riga in qualunque parte del mondo esista. La ragione per cui hai ancora una chiave auto-incrementata in questo caso è perché è più efficiente raggruppare e indicizzare la chiave auto-incrementante piuttosto che fare la stessa cosa con un guid.

Un caso in cui potresti non desiderare una chiave a incremento automatico sarebbe una tabella molti-a-molti in cui la chiave primaria è un composto delle colonne Id di altre due tabelle (potresti comunque avere una chiave a incremento automatico qui, ma io non ne vedo il punto).

Un'altra domanda è il tipo di dati della chiave auto-incrementata. L'uso di Int32 offre un intervallo di valori ampio ma relativamente limitato. Personalmente uso spesso colonne bigint per l'ID, per non aver praticamente mai bisogno di preoccuparmi di rimanere senza valori.

Come altre persone hanno avanzato la richiesta di una chiave primaria incrementale, ne farò una per un GUID:

• È garantito per essere unico
• Puoi avere un viaggio in meno nel database per i dati nella tua applicazione. (Ad esempio, per una tabella dei tipi è possibile memorizzare il GUID nell'applicazione e utilizzarlo per recuperare il record. Se si utilizza un'identità è necessario interrogare il database per nome e ho visto molte applicazioni che lo fanno per ottenere il PK e successivamente lo interroga di nuovo per ottenere tutti i dettagli).
• È utile per nascondere i dati. www.domain.com/Article/2 Fammi sapere che hai solo due articoli mentre www.domain.com/article/b08a91c5-67fc-449f-8a50-ffdf2403444a non mi dice nulla.
• È possibile unire facilmente record da diversi database.
• MSFT utilizza GUIDS per l'identità.

Modifica: punto duplicato

Come principio di buon design, ogni tavolo dovrebbe avere un modo affidabile per identificare in modo univoco una riga. Anche se è a questo che serve una chiave primaria, non sempre richiede l'esistenza di una chiave primaria. L'aggiunta di una chiave primaria a ogni tabella non è una cattiva pratica poiché fornisce l'identificazione univoca della riga, ma potrebbe non essere necessaria.

Per mantenere relazioni affidabili tra le righe di due o più tabelle, è necessario farlo tramite chiavi esterne, quindi la necessità di chiavi primarie in almeno alcune tabelle. L'aggiunta di una chiave primaria a ogni tabella semplifica l'estensione della progettazione del database quando arriva il momento di aggiungere nuove tabelle o relazioni ai dati esistenti. Pianificare in anticipo è sempre una buona cosa.

Come principio di base (forse regola rigida), il valore di una chiave primaria non dovrebbe mai cambiare per tutta la durata della riga. È saggio supporre che tutti i dati aziendali in una riga siano soggetti a modifiche nel corso della sua vita, quindi qualsiasi dato aziendale sarà un candidato scadente per una chiave primaria. Ecco perché qualcosa di astratto come un numero intero auto-incrementato è spesso una buona idea. Tuttavia, i numeri interi auto-incrementati hanno i loro limiti.

Se i tuoi dati avranno una vita solo all'interno del tuo database, gli interi con incremento automatico vanno bene. Ma, come è stato menzionato in altre risposte, se vuoi che i tuoi dati vengano condivisi, sincronizzati o che abbiano una vita al di fuori del tuo database, numeri interi auto-incrementati diventano chiavi primarie scadenti. Una scelta migliore sarà un guid (alias uuid "ID universalmente unico").

La domanda e molte delle risposte mancano del punto importante che tutte le chiavi naturali per ogni tabella risiedono esclusivamente nello schema logico per il database e tutte le chiavi surrogate per ogni tabella risiedono esclusivamente nello schema fisico per il database. altre risposte discutono solo i vantaggi relativi delle chiavi surrogate integer rispetto a GUID, senza discutere i motivi per cui le chiavi surrogate sono usate correttamente e quando.

BTW: Evitiamo l'uso del termine chiave mal definito e impreciso . Si tratta di un artefatto di modelli di dati pre-relazionali che è stato inizialmente cooptato (involontariamente) nel modello relazionale e poi cooptato di nuovo nel dominio fisico da vari fornitori di RDBMS. Il suo uso serve solo a confondere la semantica.

Si noti dal modello relazionale che, affinché lo schema logico del database sia nella prima forma normale , ogni tabella deve avere un set di campi visibile dall'utente, noto come chiave naturale, che identifica in modo univoco ogni riga della tabella. Nella maggior parte dei casi, tale chiave naturale viene prontamente identificata, ma a volte è necessario costruirla, sia come campo di pareggio che in altro modo. Tuttavia, tale chiave costruita è sempre visibile all'utente e pertanto risiede sempre nello schema logico del database.

Al contrario, qualsiasi chiave surrogata su una tabella risiede puramente nello schema fisico del database (e quindi deve sempre essere, sia per motivi di sicurezza che per il mantenimento dell'integrità del database, completamente invisibile agli utenti del database). L'unico motivo per introdurre una chiave surrogata è quello di affrontare i problemi di prestazioni nella manutenzione fisica e nell'uso del DB; che si tratti di join, replica, più origini hardware per dati o altro.

Poiché l'unica ragione per l'introduzione di una chiave surrogata è la prestazione, supponiamo che desideriamo che sia performante. Se il problema di prestazioni a portata di mano è unirsi, allora desideriamo necessariamente rendere la nostra chiave surrogata più stretta possibile (senza intralciare l'hardware, quindi numeri interi e byte brevi di solito sono fuori). Le prestazioni di join si basano su un'altezza minima dell'indice, quindi un numero intero a 4 byte è una soluzione naturale. Se il tuo problema di prestazioni è la frequenza di inserzione, un numero intero a 4 byte può anche essere una soluzione naturale (a seconda degli interni del tuo RDBMS). Se il problema di prestazioni di una tabella è la replica o più origini dati rispetto ad altre tecnologie surrogate , può essere più adatto un GUID o una chiave in due parti (ID host + intero). Personalmente non sono un favorito dei GUID ma sono convenienti.

Per riassumere, non tutte le tabelle richiedono una chiave surrogata (di qualsiasi tipo); dovrebbero essere utilizzati solo quando ritenuto necessario per l'esecuzione della tabella in esame. Indipendentemente dalla tecnologia chiave surrogata comune che preferisci, pensa attentamente alle effettive esigenze del tavolo prima di fare una scelta; cambiare la scelta della tecnologia chiave surrogata per un tavolo sarà un lavoro estenuante. Documenta la metrica delle prestazioni chiave per la tua tabella in modo che i tuoi successori capiscano le scelte fatte.

Casi speciali

1. Se i requisiti aziendali impongono una numerazione sequenziale delle transazioni a fini di audit (o altro) diversa da tale campo non è una chiave sostitutiva; è una chiave naturale (con requisiti extra). Dalla documentazione un numero intero auto-incrementante genera solo chiavi surrogate , quindi trova un altro meccanismo per generarlo. Ovviamente sarà necessaria una sorta di monitor, e se stai acquistando le tue transazioni da più siti, un sito sarà speciale , in quanto è il sito host designato per il monitor.

2. Se la tabella non sarà mai più di circa un centinaio di righe, l'altezza dell'indice è irrilevante; ogni accesso avverrà tramite una scansione della tabella. Tuttavia i confronti di stringhe su stringhe lunghe saranno ancora molto più costosi del confronto di un numero intero a 4 byte e più costosi del confronto di un GUID.

3. Una tabella di valori di codice digitati da un campo di codice char (4) dovrebbe essere performante come uno con un numero intero di 4 byte. Anche se non ne ho la prova, uso spesso il presupposto e non ho mai avuto motivo di affrontarlo.

Non solo non è una buona pratica, in realtà è descritto come un anti-pattern nel libro SQL Antipatterns di Bill Karwin.

Non tutte le tabelle hanno bisogno di uno pseudokey - una chiave primaria con un valore arbitrario, non qualcosa che abbia un valore semantico per il modello - e non c'è motivo di chiamarlo sempre id.

Questo è piuttosto universale, altrimenti dovresti convalidare che la chiave è effettivamente unica. Questo sarebbe fatto guardando tutte le altre chiavi ... il che richiederebbe molto tempo. Avere una chiave incrementale diventa costoso quando il numero del record si avvicina al valore di overflow della chiave.

Di solito, i puntatori rendono i nomi dei campi più ovvi ref_{table}o un'idea simile.

Se non è necessario indicare esternamente un record, non è necessario un ID.

Non direi che dovrebbe sempre essere fatto. Ho un tavolo qui senza chiave univoca e non ne ha bisogno. È un registro di controllo. Non ci sarà mai un aggiornamento, le query restituiranno tutte le modifiche a ciò che viene registrato, ma questo è il migliore che si possa ragionevolmente fare, ci vuole un essere umano per definire un cambiamento errato. (Se il codice avesse potuto, in primo luogo non lo avrebbe consentito!)

Un contatore di incremento automatico per una chiave primaria non è una buona idea. Questo perché è necessario tornare al database per trovare la chiave successiva e incrementarla di una prima di inserire i dati.

Detto questo, in genere utilizzerei tutto ciò che il database può fornire per la chiave primaria anziché averla come parte dell'applicazione.

Lasciando che il database lo fornisca nativamente per te, può garantire che la chiave sia unica per ciò di cui ha bisogno.

Naturalmente non tutti i database lo supportano. Nel qual caso utilizzo generalmente una tabella in cui sono archiviati i bucket delle chiavi e utilizzo intervalli alti e bassi gestiti nell'applicazione. Questa è la soluzione più efficace che trovo perché ottieni un intervallo di 10000 numeri e li incrementa automaticamente sull'istanza dell'applicazione. Un'altra istanza dell'applicazione può raccogliere un altro bucket di numeri con cui lavorare. È necessaria una primitiva di chiave primaria sufficientemente grande come una lunghezza di 64 bit.

UUID che non utilizzo come chiavi primarie perché il costo di costruirle e memorizzarle è molto più elevato che incrementare un valore lungo di una. Gli UUID affrontano ancora il paradosso del compleanno in quanto teoricamente può sorgere un duplicato.