Utilizzo della chiave cluster con incremento automatico e guida della chiave primaria insieme

Question

Utilizzo della chiave cluster con incremento automatico e guida della chiave primaria insieme

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Il mio capo è l'amministratore di db in un nuovo progetto software e ha escogitato quel progetto in cui ogni tabella avrà sia una chiave cluster ad incremento automatico e una chiave primaria di guida (o possibilmente chiavi guida composte in alcuni rari casi). Ogni relazione tra le tabelle continuerà ad utilizzare pk come riferimenti, rendendo il campo in cluster mai usato in viste, procedure, funzioni o qualsiasi codice.

Non sono un db guru, ma mi chiedo se in questo scenario valga addirittura la pena di avere un indice cluster? Voglio dire, i record non verranno aggiunti sistematicamente alla fine dei tavoli? Se è così allora perché avrei bisogno di questo campo?

programming-practices database database-design sql-server

posta Crono 19.06.2015 - 21:43

fonte

3 risposte

Leggi altre domande sui tag programming-practices database database-design sql-server

Come implementare una classe NavigationManager senza utilizzare il modello singleton I costruttori per le classi API devono mai essere pubblici oppure è sempre possibile utilizzare una fabbrica? [chiuso]

score 2 · Answer 1

Vantaggio:

GUID è univoco quindi a lungo termine se ti imbatti in questo scenario in cui puoi unirti usando solo GU piuttosto che PK + altro campo. es: ci sono vendite, ordini, aggiustamenti e c'è azione, invece di unirti usando PK e tipo di transazione, puoi semplicemente iscriverti usando Guid dato che è 99.9 ...% garantito unico.
Utilizzando GUID è possibile generare GUID dal codice in modo da rimuovere la necessità di richiamare per ottenere il nuovo PK.
Con l'auto-incremento puoi ottenere l'ultima transazione solo ordinando l'auto-incremento invece della data della transazione (Stackoverflow usando questo metodo)

score 1 · Answer 2

Come già affermato nei commenti dell'altra domanda, questa è una sciocchezza se non esegui alcuna query utilizzando l'id. Se si utilizzano solo i GUID, lasciare fuori l'indice cluster e impostare semplicemente l'indice senza cluster sui GUID.

Ma non utilizzare mai i GUID come indice cluster a meno che non si desideri eseguire uno stress test sul sottosistema I / O. ; -)

score 1 · Answer 3

Non è insolito avere diverse chiavi in una tabella e non c'è niente di fondamentalmente sbagliato in questo. Se una tabella ha più di una chiave, la scelta della chiave "primaria" non è importante o significativa solo se vuoi renderla.

Il tuo capo è corretto che sia di solito una buona idea per ogni tabella di SQL Server da raggruppare. I guids non sono buoni indici raggruppati e dove non esiste un candidato decente per il cluster a volte ha senso aggiungere una chiave intera incrementale per il clustering. Quello che penso sia sbagliato in questo caso è il suggerimento di farlo per la tabella ogni . La selezione delle chiavi dovrebbe essere basata su requisiti reali e considerazioni pratiche per ogni tabella. Una misura adatta a tutte le soluzioni non è di grande aiuto.