Qual è il modo migliore per progettare una tabella con un ID arbitrario?

GUID (il tipo di dati uniqueidentifier in SQLServer) sembra l'opzione migliore in base alle informazioni fornite. Lavoro su una grande applicazione che ha tabelle con oltre 500000 righe utilizzando GUID come chiavi primarie con alcuni join piuttosto grandi e il collo di bottiglia non è mai nei join delle chiavi primarie.

Diverse altre fonti sembrano indicare che i GUID sono una buona scelta, vale la pena provarli:

• Il link parla delle prestazioni GUID e fornisce un'indicazione chiara dei numeri sull'impatto.
• Il link offre una discreta analisi pro / contro del utilizzo di GUID rispetto a interi.

Alcuni dei problemi più importanti sembrano essere:

• Perdita di cronologia (non c'è modo di sapere quale riga è stata inserita per ultima e nessuna possibilità di rimuovere tutto inserito dopo un certo periodo di tempo), può essere risolta facilmente utilizzando una colonna 'insertdate' contenente la data e l'ora della riga è stato aggiunto
• Requisiti di archiviazione più ampi, ma a meno che non si abbia a che fare con archivi di database di grandi dimensioni è piuttosto economico
• Più difficile da ricordare e utilizzare nei test che è un problema valido ma spesso esistono alternative all'utilizzo di un GUID per identificare una riga

Sono propenso a dire che le prestazioni qui non sarebbero il problema e in base ai tuoi requisiti il GUID è un'ottima scelta, se non la tua unica.

In base a ciò che ci hai detto, GUID è il miglior modo "integrato" per soddisfare le tue esigenze. provare a trovare una chiave "roll-your-own" che soddisfi le tue esigenze sembra soggetta a errori, difficile, e come se avessi reinventato la ruota.

Nota che mentre il GUID suona bene, devi stare attento a:

1-Il tuo server deve supportarlo (ad esempio il back-end Microsoft) in modo che tu possa generarlo automaticamente per garantirne la correttezza e l'unicità.

2 - Il tuo database (s) deve supportarlo (Microsoft SQL Server per esempio), perché se si spostano i dati in un altro database, potrebbe essere ingombrante per generarlo.

3: è necessario disporre di un metodo coerente per generare i valori (dal client o dal server): in tal modo si garantisce la coerenza (si tratta di un'ipotesi personale).

4: non è necessario che l'utente lo inserisca perché è molto macchinoso.

5-Non conserva la sequenza, quindi non è possibile ripristinarla e ricominciare. ma puoi supporre che sarebbe unico.

Considering that a GUID is a string and joining on a string is an expensive task, is there a better way?

Se si crea un GUID per il PK, sarà un indice cluster sul tavolo. Il motivo per cui gli ID interi con incremento automatico sono popolari per i PK sono che nel tempo, i frammenti di indice cluster sono molto piccoli, quindi se sul PK è necessaria poca manutenzione. L'indice è sequenziale.

I GUID funzioneranno correttamente, a condizione che venga eseguita una manutenzione periodica sull'indice. Se ci sono grandi quantità di inserimenti e cancellazioni sulla tabella, basta assicurarsi che il processo che fa quegli inserimenti / cancelli ricostruisce l'indice dopo il completamento. Inoltre, nel tempo un indice GUID si frammenterà dopo molti inserti / aggiornamenti, quindi ricostruisci l'indice / PK a intervalli regolari per mantenere le query che lo utilizzano in modo ottimale.