Ti piacciono le tue chiavi primarie? [chiuso]

https://stackoverflow.com/questions/404040

03-07-2019
|

Domanda

In una discussione abbastanza animata nel mio team mi è stato fatto pensare a cosa piace alla maggior parte delle persone come chiavi primarie. Avevamo i seguenti gruppi:

Int / BigInt quali autoincrement sono chiavi primarie abbastanza buone.
Dovrebbero esserci almeno 3 colonne che compongono la chiave primaria.
ID, GUID e identificatori di riga leggibili dall'uomo devono essere trattati in modo diverso.

Qual è l'approccio migliore per i PK? Sarebbe fantastico se potessi giustificare la tua opinione. Esiste un approccio migliore di quanto sopra?

EDIT: qualcuno ha un semplice esempio / algoritmo per generare identificatori leggibili per le righe che si adattano bene?

Soluzione

Se eseguirai una sincronizzazione tra database con app collegate occasionalmente, dovresti utilizzare i GUID per le tue chiavi primarie. È un po 'una seccatura per il debug, quindi a parte questo caso tendo a mantenere quell'incremento automatico.

Gli inserimenti di incremento automatico dovrebbero essere predefiniti e non usarli dovrebbe essere giustificato.

Altri suggerimenti

Non vedo una risposta che indichi (quello che considero) il punto veramente fondamentale - vale a dire, che una chiave primaria è ciò che garantisce che non otterrai due voci nella tabella per lo stesso mondo reale entità (come modellato nel database). Questa osservazione aiuta a stabilire quali sono le buone e quali sono le cattive scelte per la chiave primaria.

Ad esempio, in una tabella di nomi e codici di stati (USA), il nome o il codice potrebbero essere la chiave primaria - costituiscono due chiavi candidate diverse e una di esse (normalmente la più breve - il codice) è scelto come chiave primaria. Nella teoria delle dipendenze funzionali (e unire le dipendenze - da 1NF a 5NF - sono le chiavi candidate che sono cruciali piuttosto che una chiave primaria.

Per un controesempio, i nomi umani generalmente fanno una scelta sbagliata per la chiave primaria. Ci sono molte persone che si chiamano "John Smith" o altri nomi simili; anche prendendo in considerazione il secondo nome (ricordate: non tutti ne hanno uno - per esempio, io no), c'è molto spazio per la duplicazione. Di conseguenza, le persone non usano i nomi come chiavi primarie. Inventano chiavi artificiali come il numero di previdenza sociale (SSN) o il numero di dipendente e le usano per designare l'individuo.

Una chiave primaria ideale è breve, unica, memorabile e naturale. Di queste caratteristiche, l'unicità è obbligatoria; il resto deve flettere dati i vincoli dei dati del mondo reale.

Quando si tratta di determinare la chiave primaria di una determinata tabella, pertanto, è necessario esaminare ciò che rappresenta quella tabella. Quale set o set di valori di colonna nella tabella identifica in modo univoco ogni riga nella tabella? Quelle sono le chiavi candidate. Ora, se ogni chiave candidata è composta da 4 o 5 colonne, potresti decidere che sono troppo goffi per creare una buona chiave primaria (principalmente per motivi di scarsità). In tali circostanze, potresti introdurre una chiave surrogata, un numero generato artificialmente. Molto spesso (ma non sempre) un semplice numero intero a 32 bit è sufficiente per la chiave surrogata. Quindi designare questa chiave surrogata come chiave primaria.

Tuttavia, devi assicurarti comunque che le altre chiavi candidate (anche per la chiave surrogata sia una chiave candidata, così come la chiave primaria scelta) siano tutte mantenute come identificatore univoco, normalmente posizionando un vincolo univoco per quegli insiemi di colonne.

A volte, le persone trovano difficile identificare ciò che rende unica una riga, ma dovrebbe esserci qualcosa per farlo, perché semplicemente ripetere un'informazione non la rende più vera. E se non stai attento e ottieni due (o più) righe che pretendono di memorizzare le stesse informazioni, e quindi devi aggiornare le informazioni, c'è un pericolo (specialmente se usi i cursori) che aggiornerai solo una riga piuttosto che ogni riga, quindi le righe non sono sincronizzate e nessuno sa quale riga contiene le informazioni corrette.

Questa è una visione piuttosto rigida, per alcuni aspetti.

Non ho particolari problemi con l'uso di un GUID quando sono necessari, ma tendono ad essere grandi (come in 16-64 byte) e sono usati troppo spesso. Molto spesso sarebbe sufficiente un valore di 4 byte perfettamente buono. L'uso di un GUID in cui un valore di 4 byte sarebbe sufficiente a sprecare spazio su disco e rallenta anche l'accesso indicizzato ai dati poiché ci sono meno valori per pagina di indice, quindi l'indice sarà più profondo e dovranno essere lette più pagine per raggiungere informazioni.

Questa è solo una questione religiosa perché le persone cercano una risposta giusta universale. Il fatto che sia il tuo team sia questo thread SO mostrino un tale disaccordo dovrebbe essere un indizio del fatto che ci sono buone ragioni per utilizzare tutte le soluzioni che descrivi, in circostanze diverse.

Le chiavi surrogate sono utili quando nessun altro attributo o insieme di attributi nella tabella è adatto per identificare le righe in modo univoco.
Le chiavi naturali sono preferite, quando possibile, per rendere la tabella più leggibile dall'uomo. Le chiavi naturali consentono inoltre alla chiave esterna in una tabella dipendente di contenere un valore reale anziché un ID surrogato. Per esempio. quando è necessario memorizzare state (CA, TX, NY) è possibile utilizzare una chiave naturale char (2) anziché un int.
Utilizza le chiavi primarie composte ove appropriato. Non aggiungere un " id " chiave surrogata inutilmente quando esiste una chiave composta perfettamente valida (questo è particolarmente vero in molte tabelle a molti). Un mandato per una chiave a tre colonne in ogni tabella è un'assurdità assoluta.
I GUID sono una soluzione quando è necessario preservare l'unicità su più siti. Sono inoltre utili se i valori nella chiave primaria devono essere univoci, ma non ordinati o consecutivi.
INT vs. BIGINT: non è comune che una tabella richieda un intervallo di 64 bit per le chiavi primarie, ma con la crescente disponibilità di hardware a 64 bit non dovrebbe essere un peso, e dà più sicurezza che non traboccherai. INT è ovviamente più piccolo, quindi se lo spazio è limitato può dare un leggero vantaggio.

Mi piace Il blog del programmatore di database come fonte per questo tipo di informazioni.

3 colonne per una chiave primaria? Direi che le colonne dovrebbero avere vincoli univoci appropriati come richiesto dalle regole aziendali, ma avrei comunque una chiave surrogata separata. Le chiavi composte significano che la logica aziendale entra nella chiave. Se la logica cambia, l'intero schema viene rovinato.

Mi piace il mio unico.

Vado sempre con la chiave surrogata. Una chiave surrogata (in genere una colonna di identità, autoincremento o GUID) è una chiave in cui la chiave non è presente nei dati stessi. Una chiave naturale, d'altra parte, è quella che, da sola, identifica in modo univoco la riga. Per quanto posso dire nella vita, quasi non ci sono chiavi naturali reali . Neanche cose come SSN negli Stati Uniti sono una chiave naturale. Le chiavi primarie composite sono un disastro in attesa di accadere. Non è possibile modificare nessuno di quei dati (che è il principale svantaggio di qualsiasi chiave naturale, composita o meno), ma peggio è che con una chiave composita, ora è necessario perpetuare i dati di chiave in ogni tabella correlata. Che spreco gigantesco.

Ora, per la selezione della chiave surrogata, mi attengo alle colonne di identità (lavoro principalmente in MS SQL Server). I GUID sono troppo grandi e Microsoft consiglia di utilizzare contro come PK. Se hai più server, tutto ciò che devi fare è incrementare 10 o 20 o qualunque cosa tu pensi il numero massimo di server di cui avrai mai bisogno per sincronizzare / espandere, e semplicemente aumentare il seme per ogni tabella su ciascun server successivo e non avrai mai una collisione di dati.

Naturalmente, a causa dell'incremento, faccio della colonna identità un BigInt (altrimenti noto come un lungo [64 bit]).

Facendo un po 'di matematica, anche se fai l'incremento 100, puoi comunque avere 92.233.720.368.547.758 (> 92 quadrilioni) righe nella tua tabella.

Penso che l'uso della parola "Primario", nella frase "Primario" La chiave è in un senso reale, fuorviante.

Innanzitutto, utilizza la definizione che una "chiave" " è un attributo o un insieme di attributi che devono essere univoci nella tabella,

Quindi, avere una chiave serve a scopi spesso reciprocamente incoerenti.

Da utilizzare come condizioni di join per uno o più record in tabelle figlio che hanno una relazione con questa tabella padre. (Definizione esplicita o implicita di una chiave esterna in quelle tabelle secondarie)
(correlato) Garantire che i record figlio debbano avere un record padre nella scheda padre; e (L'FK della tabella figlio deve esistere come chiave nella tabella padre)
Per aumentare le prestazioni delle query che devono individuare rapidamente un record / riga specifici nella tabella.
Per garantire la coerenza dei dati impedendo l'inserimento di righe duplicate che rappresentano la stessa entità logica nella tabella. (Questa è spesso chiamata chiave "naturale" e dovrebbe essere costituita da attributi di tabella (entità) che sono relativamente invarianti.)

Chiaramente, qualsiasi chiave non significativa, non naturale (come un GUID o un numero intero generato automaticamente è totalmente incapace di soddisfare # 4.

Ma spesso, con molte (la maggior parte) di tabelle, una chiave totalmente naturale che può fornire il n. 4 sarà spesso costituita da più attributi e sarà eccessivamente ampia o talmente ampia da usarla per gli scopi n. 1, n. 2 o n. 3 causerà conseguenze inaccettabili sulle prestazioni.

La risposta è semplice. Utilizza entrambi. Utilizzare una chiave integrale auto-generante semplice per tutti i join e gli FK in altre tabelle figlio, ma assicurarsi che ogni tabella che richiede coerenza dei dati (pochissime tabelle non) disponga di una chiave univoca naturale alternativa che impedirà l'inserimento di righe di dati incoerenti. .. Inoltre, se hai sempre entrambi, allora tutte le obiezioni contro l'uso di una chiave naturale (cosa succede se cambia? Devo cambiare ogni posto a cui viene indicato come FK) diventano discutibili, poiché non lo usi. .. Lo stai usando solo nell'unica tabella in cui è un PK, per evitare dati duplicati incoerenti ...

Per quanto riguarda i GUID, fare molta attenzione ad usarli, poiché l'uso delle guide in un indice può ridurre la frammentazione dell'indice. Gli algoritmi più comuni usati per crearli mettono il "casuale" parte del guid nelle posizioni di bit più significative ... Ciò aumenta il requisito per la deframmentazione / reindicizzazione periodica dell'indice quando vengono aggiunte nuove righe.

Leggermente fuori tema, ma mi sento in dovere di entrare in contatto con ...

Se la tua chiave primaria è un GUID, non lo rende un indice cluster . Poiché i GUID non sono sequenziali, i dati verranno riorganizzati su disco durante quasi ogni inserimento. (Che schifo.) Se si usano GUID come chiavi primarie, dovrebbero essere indici non cluster.

Una cosa che non dovresti mai fare è usare una chiave intelligente. Questa è una chiave in cui le informazioni sul record sono codificate nella chiave stessa e alla fine ti morderanno.

Ho lavorato in un posto, dove la chiave primaria era l'ID account, che era una combinazione di lettere e numeri. Non ricordo alcun dettaglio, ma, per esempio, quegli account che erano di un certo tipo, sarebbero compresi nell'intervallo 600 e di un altro tipo, iniziarono con 400. È stato fantastico, fino a quando quel cliente non ha deciso di chiedere entrambi tipi di lavoro. O ha cambiato il tipo di lavoro svolto.

Un altro posto, ha usato la posizione nell'albero come chiave primaria per i record. Quindi ci sarebbero record come il seguente.

Cat1.subcatA.record1
Cat1.subcatA.record2
Cat1.subcatB.record1
Cat2.subcatA.record1

Naturalmente, la prima cosa che i clienti desideravano era un modo per spostare gli oggetti nella struttura. L'intero set di software è morto prima che accadesse.

Per favore, per favore, per favore, se stai scrivendo codice che dovrò mai mantenere, per favore non usare una chiave intelligente!

Sono un fan dell'incremento automatico come chiave primaria. So nel profondo del mio cuore che si tratta di un cop-out, ma rende così facile ordinare i dati per quando sono stati aggiunti (ORDER BY ID DESC, per esempio).

3 colonne sembrano terribilmente dure da analizzare umanamente.

E questo è il compromesso: quanta capacità relazionale ti serve, rispetto a rendere QUESTA TABELLA DIRITTA QUI comprensibile a un umano che la interroga (rispetto alla procedura memorizzata o all'interfaccia programmatica).

l'auto-incremento è per noi umani. : - (

In generale, dipende.

Personalmente, mi piacciono gli autoincrement ints.

Ma una cosa che posso dirti è non fidarti mai dei dati di altre fonti come chiave. Lo giuro, ogni volta che l'ho fatto torna a mordermi. Bene, mai più!

Dovrebbero esserci almeno 3 colonne che compongono la chiave primaria.

Non capisco.

Stai parlando di una "chiave naturale", ad es. " nome e data di nascita " ;? Una chiave naturale potrebbe essere l'ideale se esiste, ma la maggior parte dei candidati per una chiave naturale non sono univoci (più persone con lo stesso nome) o non sono costanti (qualcuno può cambiare il loro nome).

Int / BigInt quali autoincrement sono chiavi primarie abbastanza buone.

Preferisco Guid. Un potenziale problema con l'autoincremento è che il valore (ad es. "ID ordine") è assegnato dall'istanza del database (ad es. Dal "database di vendita") ... che non funzionerà completamente (invece si iniziano a richiedere chiavi composte ) se hai mai bisogno di unire i dati creati da più di un'istanza di database (ad esempio da diversi uffici vendite ciascuno con il proprio database).

RE GUID

Fai attenzione se questo sarà davvero un grande database davvero VERAMENTE DAVVERO , molto carico e accesso veloce.

Nel mio ultimo lavoro, dove avevamo database da 100 a 500 milioni di record, i nostri ragazzi del database hanno fortemente discusso contro i GUID e per un numero decimale di dimensioni appropriate. Hanno ritenuto che (sotto Oracle) la differenza di dimensione nella memoria interna per una stringa Guid - rispetto a un valore decimale avrebbe fatto una differenza molto evidente nelle ricerche. (Tasti più grandi = alberi più profondi da attraversare)

La natura casuale dei GUID riduce anche in modo significativo il fattore di riempimento per le pagine dell'indice, aumentando notevolmente gli strappi e l'I / O del disco.

Colonne di incremento automatico. Sono in grado di far funzionare perfettamente il mio codice con SQL Server o Oracle, uno usando l'identità l'altro usando sequenze attraverso il mio DAL, e non potrei essere più felice. Sono d'accordo, a volte i GUID sono necessari se stai eseguendo la replica o inviando dati per riceverli in un secondo momento dopo l'elaborazione.

Ho sempre usato una chiave surrogata, un numero intero autoincrementato chiamato 'id'. Vedo molte ragioni per farlo anche quando un'altra opzione è ovvia:

Coerenza
Indipendente dai dati (unico, non distrutto dalle modifiche al formato)
Human-leggibile

... e nessuna ragione ragionevole per non:

Ambiguità nei join? - Aliasing tables è una pratica migliore, IMHO
Tabelle ottimali? - La rimozione di un byte per voce è l'ottimizzazione prematura, IMHO
Decisione per tavolo? - Non più coerente
Problemi di ridimensionamento? - Eh? Perché?
Struttura gerarchica dei dati? - È denormalizzante, un altro argomento religioso. Basti dire che sono un fan in alcune circostanze in teoria, ma mai in pratica :)

ragioni sensate contro le quali non ho pensato o incontrato ancora sono sempre ben accette ...

Questo è un classico " dipende " ;. Non esiste una risposta giusta per ogni progetto. Mi piacciono le cose diverse per situazioni diverse. Dipende se sto usando un ORM e cosa supporta. Dipende dall'architettura generale (distribuita o meno, ecc.). Basta sceglierne uno che ritieni possa funzionare e passare a discutere su schede e spazi.

Tendo a utilizzare l'opzione n. 1 o n. 3 a seconda delle dimensioni, del numero di persone che si connettono e se si tratta di una situazione con più server di database o meno.

L'opzione n. 2 non ha molto senso per me. Se uno dei tre non è sufficiente per identificare un record univoco, è possibile (senza passare per ulteriori macchinazioni) due hanno due record mostrati con gli stessi valori in tutte e tre le colonne. Se vuoi imporre l'unicità su qualsiasi combinazione dei tre, aggiungi semplicemente un indice per loro.

Ho usato solo un int di incremento automatico o un GUID. Il 99% delle volte ho usato int auto-increment. È proprio quello che mi è stato insegnato a usare quando ho appreso per la prima volta dei database e non ho mai incontrato un motivo per non usarli (anche se conosco i motivi per cui un GUID sarebbe meglio).

Mi piacciono gli incrementi automatici perché aiuta con la leggibilità. Ad esempio, posso dire "dai un'occhiata al record 129383" ed è abbastanza facile per qualcuno entrare e trovarlo. Con un GUID è quasi impossibile farlo.

Dopo una risposta di base alla definizione, ciò che costituisce una buona chiave primaria viene lasciato in gran parte alla religione e agli argomenti di rottura. Se hai qualcosa che è e sarà sempre mappato in modo univoco su una singola riga, funzionerà bene come chiave primaria. Oltre quel punto, ci sono altre considerazioni:

La definizione della chiave primaria non è eccessivamente complessa? Evita di introdurre complessità inutili per il gusto di seguire una "best practice"?
Esiste una chiave primaria possibile migliore che richiederebbe meno overhead per la gestione del database (ovvero INTEGER vs. VARCHAR, ecc.)?
Sono ASSOLUTAMENTE sicuro che l'unicità e la definizione invariante della mia chiave primaria non cambieranno?

Quest'ultimo è probabilmente ciò che attira la maggior parte delle persone a usare cose come GUID o colonne intere auto-incrementanti, perché fare affidamento su cose come indirizzi, numeri di telefono, nome / cognome, ecc., semplicemente non lo tagliano. L'unico invariante delle persone a cui riesco a pensare sono gli SSN, ma poi non sono nemmeno sicuro al 100% di quelli che restano per sempre unici.

Speriamo che questo aiuti ad aggiungere un po 'di chiarezza ...

Il modo in cui mi avvicino alle chiavi primarie (e penso che sia la migliore) è di evitare di avere un "quot" predefinito " approccio. Ciò significa invece di limitarsi a schiaffeggiare un numero intero auto-incrementante e chiamandolo un giorno guardo il problema e dico "c'è una colonna o un gruppo di colonne che saranno sempre inammissibili e non cambieranno?" Se la risposta è sì, seguo questo approccio.

Quasi sempre numeri interi.

Hanno altri buoni motivi oltre a essere più piccoli / veloci da elaborare. Quale preferiresti scrivere - "404040" o " 3463b5a2-a02b-4fd4-aa0f-1d3c0450026c " ;?

Solo leggermente rilevante, ma una cosa che ho iniziato a fare recentemente quando ho piccole tabelle di classificazione (essenzialmente quelle che rappresenterebbero ENUM nel codice) è che trasformerò la chiave primaria in un carattere (3) o carattere (4 ). Quindi rendo quelle chiavi primarie rappresentative del valore di ricerca.

Ad esempio, ho un sistema di offerte per i nostri agenti di vendita interni. Abbiamo " Categorie di costo " che a ogni elemento pubblicitario è assegnato uno dei ... Quindi ho una tabella di ricerca del tipo chiamata 'tCostCategories', dove la chiave primaria è 'MTL', 'SVC', 'TRV', 'TAX', 'ODC'. Altre colonne nella tabella di ricerca contengono ulteriori dettagli, come i normali significati inglesi dei codici, "Materiale", "Servizio", "Viaggio", "Imposte", "Altri costi diretti" e così via .

Questo è davvero bello perché non utilizza più spazio di un int e quando si guardano i dati di origine, non è necessario collegare la tabella di ricerca per sapere quale diavolo sia il valore. Ad esempio, una riga di citazione potrebbe apparire come:

1 PartNumber $ 40 MTL
2 AltroPartNumber $ 29,99 SVC
3 PartNumber2 $ 150 TRV

È molto più facile che usare un int per rappresentare le categorie e quindi collegare 1, 2, 3 su tutte le linee - hai i dati proprio lì davanti a te e le prestazioni non sembrano affatto influenzate (non che ho veramente testato.)

Per quanto riguarda la vera domanda ... Mi piacciono gli identificatori unici RowGUID. Non sono al 100% su questo, ma non tutte le righe hanno comunque RowGuid interno ?? In tal caso, l'utilizzo del RowGuid richiederebbe effettivamente meno spazio degli ints (o di qualsiasi altra cosa). Tutto quello che so è che se è abbastanza buono per M $ da usare in GreatPlains, allora è abbastanza buono per me. (Dovrei anatra ??)

Oh, un motivo in più per cui utilizzo i GUID: utilizzo una struttura gerarchica di dati. Cioè, ho una tabella "Azienda" e una tabella "Venditore" per le quali corrispondono le chiavi primarie. Ma ho anche una tabella "Produttore" che "eredita" anche dalla Società. I campi comuni a Venditori e Produttori non compaiono in quelle tabelle, ma appaiono in Azienda. In questa configurazione, l'utilizzo di int è molto più doloroso delle guide. Per lo meno, non è possibile utilizzare le chiavi primarie di identità.

Mi piacciono le chiavi naturali, ogni volta che posso fidarmi di loro. Sono disposto a pagare un piccolo prezzo di prestazione al fine di utilizzare le chiavi che hanno senso per gli esperti in materia.

Per le tabelle che descrivono le entità, dovrebbe esserci una semplice chiave naturale che identifichi le singole istanze nello stesso modo in cui fanno le persone. Se l'oggetto non ha identificatori affidabili per una delle entità, ricorreremo a una chiave surrogata.

Per le tabelle che descrivono le relazioni, utilizzo una chiave composta, in cui ogni componente fa riferimento a un'entità che partecipa alla relazione e quindi a una riga in una tabella di entità. Ancora una volta, l'hit di prestazioni per l'utilizzo di una chiave composta è generalmente minimo.

Come altri hanno sottolineato, il termine "chiave primaria" è un po 'fuorviante. Nel Modello di dati relazionali, il termine utilizzato è "chiavi candidate". Potrebbero esserci più chiavi candidate per un singolo tavolo. Logicamente, ognuno è buono come un altro. Scegliendone uno come "primario" e fare tutti i riferimenti tramite quella chiave è semplicemente una scelta che il progettista può fare.

Guids.period.

Nel caso in cui sia necessario ridimensionare o è necessario assegnare la chiave primaria in modo alternativo, saranno loro amici. Puoi aggiungere indici per tutto il resto.

aggiorna per chiarire la mia dichiarazione.

Ho lavorato su molti tipi diversi di siti. Dalle piccole offerte di server singolo a quelle di grandi dimensioni supportate da più DB e server Web. Ci sono state certamente delle app che sarebbero andate bene con l'incremento automatico degli ints come chiavi primarie. Tuttavia, quelli non si adattano al modello di come faccio le cose.

Quando si utilizza un GUID è possibile generare l'ID ovunque. Potrebbe essere generato da un server remoto, la tua app Web, all'interno del database stesso o anche all'interno di più database in una situazione multimaster.

D'altra parte, un INT auto-incrementato può essere generato in sicurezza solo all'interno del database primario. Ancora una volta, questo potrebbe andare bene se hai un'applicazione che sarà intimamente legata a quella di backup del server DB e il ridimensionamento non è qualcosa di cui ti preoccupi.

Certo, l'uso dei GUID implica che devi avere processi di reindicizzazione notturna. Tuttavia, se si utilizza qualcosa di diverso da un INT con incremento automatico, è necessario farlo comunque. Diamine, anche con un INT come primario è probabile che tu abbia altri indici che devono essere rigenerati per gestire la frammentazione. Pertanto, l'utilizzo dei GUID non aggiunge esattamente un altro problema poiché tali attività devono essere eseguite indipendentemente.

Se dai un'occhiata alle app più grandi là fuori noterai qualcosa di importante: usano tutti i GUID con codifica Base64 come chiavi. Il motivo è semplice, l'uso dei GUID consente di ridimensionare facilmente fuori mentre ci possono essere molti cerchi da saltare quando si tenta di ridimensionare gli INT.

La nostra ultima app attraversa un periodo di inserti pesanti che dura circa un mese. Successivamente, oltre il 90% delle query sono tutte selezionate per il reporting. Per aumentare la capacità, posso visualizzare altri server DB durante questo periodo di inserimento di grandi dimensioni; e successivamente unirli facilmente in un singolo DB per i rapporti. Tentare di farlo con gli INT sarebbe un incubo assoluto.

Francamente, ogni volta che si raggruppa un database o si configura la replica, il server DB richiederà comunque di avere GUID sul tavolo. Quindi, se pensi che il tuo sistema potrebbe aver bisogno di crescere, scegli quello che va bene.

Questo è un argomento complesso, che tu l'abbia realizzato o meno. Potrebbe rientrare nella sezione di queste FAQ StackOverflow.

Che tipo di domande non dovrei porre qui?

Evita di porre domande soggettive, argomentative o che richiedono una discussione estesa. Questo è un posto per domande a cui è possibile rispondere!

Questo è stato discusso per anni e continuerà a essere discusso per anni. L'unico accenno di consenso che ho visto è che le risposte sono in qualche modo prevedibili a seconda se stai chiedendo a un ragazzo OO (i GUID sono l'unico modo per andare!), Un modellatore di dati (le chiavi naturali sono l'unico modo per andare!), o un DBA orientato alle prestazioni (gli INT sono l'unica strada da percorrere!).

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow