È una buona idea usare rowguid come chiave unica nella progettazione del database?

Question

SQL Server fornisce il tipo [rowguid]. Mi piace usare questo come chiave primaria univoca, per identificare una riga per l'aggiornamento. Il vantaggio si presenta se scarichi la tabella e la ricarichi, senza problemi con le colonne SerialNo (identità).

Nel caso speciale di database distribuiti come copie offline su notebook o qualcosa del genere, nient'altro funziona.

Cosa ne pensi? Troppo sovraccarico?

Answer 1

Come chiave primaria in senso logico (identificando in modo univoco le tue righe) - sì, assolutamente, ha un senso totale.

MA: in SQL Server, la chiave primaria è per impostazione predefinita anche la chiave di clustering sulla tabella e utilizza un ROWGUID come la chiave di clustering è davvero una pessima idea. Vedi gli eccellenti GUID di Kimberly Tripp come articolo PRIMARY e / o chiave di clustering per motivi approfonditi perché non utilizzare GUID per il clustering.

Poiché il GUID è per definizione casuale, si avrà un'orribile frammentazione dell'indice e quindi prestazioni davvero pessime su istruzioni di inserimento, aggiornamento, eliminazione e selezione.

Inoltre, poiché la chiave di clustering viene aggiunta a tutti i campi di ogni indice non cluster sulla tabella, si sta sprecando molto spazio, sia su disco che nella RAM del server, quando si utilizza GUID a 16 byte e INT a 4 byte.

Quindi: sì, come chiave primaria, un ROWGUID ha i suoi meriti - ma se lo usi, evita decisamente di usare quella colonna come chiave di clustering nella tabella! Usa un INT IDENTITY () o qualcosa di simile per quello.

Per una chiave di clustering, idealmente dovresti cercare quattro funzionalità:

• stabile (non cambia mai)
• Unique
• il più piccolo possibile
• sempre crescente

INT IDENTITY () si adatta idealmente a tale esigenza. E sì - la chiave di clustering deve essere univoca poiché viene utilizzata per individuare fisicamente una riga nella tabella - se si sceglie una colonna che non può essere garantita come unica, SQL Server aggiungerà effettivamente un identificatore a quattro byte alla chiave di clustering - di nuovo, non qualcosa che vuoi avere ....

Scopri Il dibattito sull'indice cluster continua - un altro meraviglioso e approfondito articolo di Kim Tripp (il "Queen of SQL Server Indexing") in cui spiega tutti questi requisiti in modo molto accurato e completo.

MARC

Answer 2

Il problema con rowguid è che se lo si utilizza per l'indice cluster, si finisce per ricalcolare costantemente le pagine della tabella per gli inserimenti dei record. Una guida sequenziale (NEWSEQUENTIALID ()) spesso funziona meglio.

Answer 3

La nostra applicazione offline viene utilizzata nelle filiali e abbiamo un database centrale nella nostra sede principale. Per sincronizzare il database nel database centrale abbiamo usato la colonna rowguid in tutte le tabelle. Possono esserci soluzioni migliori ma per noi è più facile. Non abbiamo riscontrato grossi problemi fino alla data negli ultimi 3 anni.

Answer 4

Contrariamente alla risposta accettata, il tipo di dati uniqueidentifier in SQL Server è in effetti un buon candidato per una chiave di clustering primaria; fintanto che lo mantieni sequenziale.

Questo è facilmente realizzabile usando (newsequentialid ()) come valore predefinito per la colonna.

Se in realtà leggi L'articolo di Kimberly Tripp scoprirai che i GUID generati in sequenza sono in realtà un buon candidato per le chiavi di clustering primarie in termini di frammentazione e l'unico aspetto negativo è la dimensione.

Se si dispone di righe di grandi dimensioni con pochi indici, i pochi byte in più in un GUID potrebbero essere trascurabili. Sicuramente il problema si presenta se hai file brevi con numerosi indici, ma questo è qualcosa che devi valutare a seconda della tua situazione.

L'uso di identificativi univoci sequenziali ha molto senso quando si intende utilizzare la replica di tipo merge, soprattutto quando si ha a che fare con il seeding dell'identità e i guai che ne conseguono.

L'archiviazione dei server non è economica, ma preferirei avere un database che utilizza un po 'più di spazio di uno che si blocca quando gli intervalli di identità assegnati automaticamente si sovrappongono.