Utilizzo di un GUID e un numero intero con incremento automatico

Question

Ho studiato l'utilizzo dei GUID come chiavi primarie nei database. Finora, i professionisti sembrano superare gli svantaggi. Tuttavia, vedo un punto in cui i GUID potrebbero non essere ciò che voglio.

Nella mia applicazione, gli utenti dovrebbero essere in grado di identificare gli oggetti in base a un ID facile da usare. Ad esempio, se desiderano ottenere un prodotto specifico senza digitare il nome completo, possono utilizzare l'ID del prodotto. I GUID non sono facili da ricordare per qualcosa del genere.

La soluzione a cui stavo pensando è di utilizzare sia un GUID che un intero autoincrementante. Il GUID sarebbe la chiave primaria della riga, mentre il numero intero a incremento automatico sarebbe un indice utilizzato dalle funzioni di filtro dell'applicazione. Tutte le istruzioni SQL SELECT, UPDATE, DELETE useranno comunque il GUID.

Il motivo principale per cui desidero utilizzare GUID è impedire interruzioni durante l'unione di due database. Se Database # 1 e Database # 2 hanno entrambi un prodotto n. 2, lo script di importazione dovrebbe modificare l'ID e tutte le chiavi esterne che si riferiscono ad esso. Con GUID, devo solo modificare l'ID user-friendly nella tabella stessa, mentre le chiavi esterne utilizzerebbero il GUID univoco per ogni record importato e quindi funzioneranno senza modifiche.

Quindi, la mia domanda è: ci sono dei problemi principali (oltre alla dimensione del campo GUID e una facile frammentazione delle pagine) con un indice intero auto-incrementante e una chiave primaria GUID?

Answer 1

Tendo sempre a utilizzare le chiavi primarie surrogate nel mio database. Ovvero: quelle chiavi primarie non hanno alcun significato effettivo nel dominio del problema e, quindi, quelle chiavi primarie non vengono mai esposte agli utenti. (Se questa chiave surrogata primaria è di tipo GUID o un'identità, non mi interessa, questo dipende dai requisiti).

Se si dice che gli utenti dovrebbero essere in grado di identificare gli oggetti in base a un ID user-friendly, allora, penso che questo ID user-friendly sia un valore che appartiene al tuo "dominio problematico". Ciò significa che questo ID deve essere effettivamente un attributo nella tabella, ma non deve essere utilizzato come chiave primaria nella tabella.

Ciò consente inoltre di modificare facilmente il valore di tale ID di facile utilizzo (se necessario) senza dover preoccuparsi di modificare anche le chiavi esterne correlate.

Answer 2

In MySQL, è necessario impostare il vostro numerico ID come PRIMARY KEY, come AUTO_INCREMENT può essere solo il PRIMARY KEY, il che significa che dovrebbe anche essere NOT NULL.

È ancora possibile definire un UNIQUE INDEX sulla vostra colonna GUID e usarlo ovunque, anche se una tabella InnoDB verrà cluster sul numerica id, non sul GUID.

Answer 3

C'è una scuola di pensiero là fuori che dice che non dovresti mai esporre i tuoi ID surrogati al mondo esterno. Quindi direbbero che se vuoi un documento d'identità, dovresti usare qualcos'altro per questo.

This Wikipedia article, per esempio, dice questo:

Disassociation

I valori delle chiavi surrogate generate - perché sono generati e arbitrario - non hanno alcuna relazione con il mondo reale significato del dati tenuti in fila. Quando si ispeziona un'altra riga che contiene un riferimento di chiave esterna a una chiave surrogata, non è possibile che risolva il suo significato tenendo conto di i dati nella riga stessa. Un livello è aggiunto a questo riferimento indiretto per ogni join di chiave esterna che è necessario navigare mentre si tenta di creare il senso di un elemento di dati . Ciò può anche rendere più difficile il controllo , poiché i dati errati non sono evidenti sull'ispezione .

Anche le chiavi surrogate non sono naturali per i dati che vengono esportati e condivisi. Una particolare difficoltà è che due istanze di uno schema può contenere record che logicamente significano la stessa cosa (vale a dire - sono le stesse in un certo senso business), ma che hanno una diversa chiave a causa della storia come sono stati assegnati i tasti. Un approccio per affrontare questo è quello adottare la regola che le chiavi surrogate sono mai esportate o importate: sono mai esposta all'esterno del database ad eccezione dei dati come transitori (più ovviamente, in esecuzione di applicazioni che hanno un "vivo "connessione al database ).

Answer 4

"Perché "gli utenti dovrebbero essere in grado di identificare gli oggetti sulla base di un'user-friendly ID"?

A mio parere, gli utenti dovrebbero itentify record utilizzando i codici.

Diciamo che il database contiene prodotti (come lo hai menzionato in Domanda) Non sarebbe meglio se avessero codici per rappresentare prodotti, che gli utenti potrebbero inserire.

Diciamo che hai tavoli e sedie, come utente, preferirei usando tbl e chr di 1 e 2 per identificare di cosa sto parlando.

Answer 5

Per essere più specifiche sulla tua domanda, sì, ci sono altri problemi con l'utilizzo di GUID come chiavi primarie nei database:

Il problema non è tanto con l'utilizzo di un GUID come chiave primaria, la sua utilizzando un GUID non sequenziale come indice cluster per una tabella.

Il takeaway è utilizzare entrambi gli altri campi come indice cluster o utilizzare un GUID sequenziale per evitare questa frammentazione.