Stringhe come chiavi primarie nel database SQL

Non ho molta familiarità con i database e le teorie su come funzionano. È più lento dal punto di vista delle prestazioni (inserimento / aggiornamento / interrogazione) utilizzare Stringhe per chiavi primarie rispetto agli interi?

Tecnicamente sì, ma se una stringa ha senso essere la chiave primaria, probabilmente dovresti usarla. Tutto dipende dalla dimensione della tabella per la quale lo stai creando e dalla lunghezza della stringa che diventerà la chiave primaria (stringhe più lunghe == più difficili da confrontare). Non userei necessariamente una stringa per una tabella che ha milioni di righe, ma la quantità di rallentamento delle prestazioni che otterrai usando una stringa su tabelle più piccole sarà minima per il mal di testa che puoi avere avendo un numero intero che non Non intendo nulla in relazione ai dati.

Un altro problema con l’utilizzo di Strings come chiave primaria è che, poiché l’indice viene costantemente inserito in ordine sequenziale, quando viene creata una nuova chiave che si trova nel mezzo dell’ordine, l’indice deve essere riscritto … se si utilizza un’auto numero intero, la nuova chiave viene aggiunta alla fine dell’indice.

Inserimenti in una tabella con un indice cluster in cui l’inserimento avviene nel mezzo della sequenza NON causa la riscrittura dell’indice. Non causa la riscrittura delle pagine che comprendono i dati. Se c’è spazio nella pagina in cui la riga andrà, allora sarà posizionata in quella pagina. La singola pagina verrà riformattata per posizionare la riga nel posto giusto nella pagina. Quando la pagina è piena, si verifica una divisione della pagina, con metà delle righe sulla pagina che vanno a una pagina e metà sull’altra. Le pagine vengono quindi ricollegate all’elenco di pagine collegate che comprendono dati di tabelle con l’indice cluster. Al massimo, finirai per scrivere 2 pagine di database.

Le stringhe sono più lente in join e nella vita reale raramente sono davvero uniche (anche quando dovrebbero essere). L’unico vantaggio è che possono ridurre il numero di join se si accede alla tabella principale solo per ottenere il nome. Tuttavia, anche le stringhe sono spesso soggette a modifiche, creando così il problema di dover correggere tutti i record correlati quando il nome della società cambia o la persona si sposa. Questo può essere un enorme successo in termini di prestazioni e se tutte le tabelle che dovrebbero essere correlate in qualche modo non sono correlate (questo accade più spesso di quanto si pensi), allora si potrebbero avere anche discrepanze nei dati. Un numero intero che non cambierà mai durante la vita del disco è una scelta molto più sicura dal punto di vista dell’integrità dei dati e dal punto di vista delle prestazioni. Le chiavi naturali di solito non sono così buone per il mantenimento dei dati.

Voglio anche sottolineare che il meglio dei due mondi è spesso quello di utilizzare una chiave autoincrementing (o in alcuni casi specializzati, un GUID) come PK e quindi inserire un indice univoco sulla chiave naturale. Ottieni i join più veloci, non ottieni record duplicati e non devi aggiornare un milione di record figlio perché il nome di un’azienda è cambiato.

Non importa quello che usi come chiave primaria fintanto che è UNICO. Se ti preoccupi della velocità o di una buona progettazione del database, utilizza l’int a meno che non prevedi di replicare i dati, quindi utilizza un GUID.

Se si tratta di un database di accesso o di una piccola app allora chi se ne frega davvero. Penso che la ragione per cui la maggior parte di noi sviluppatori schiaffeggia il vecchio int o guid di fronte è perché i progetti hanno un modo di crescere su di noi, e tu vuoi lasciarti la possibilità di crescere.

Troppe variabili. Dipende dalla dimensione della tabella, dagli indici, dalla natura del dominio della chiave della stringa …

In generale , gli interi saranno più veloci. Ma la differenza sarà abbastanza grande da preoccuparsene? È difficile da dire.

Inoltre, qual è la tua motivazione per la scelta degli archi? Anche le chiavi di incremento automatico numerico sono spesso molto più semplici . È semantica? Convenienza? Problemi di replica / disconnessi? La tua risposta qui potrebbe limitare le tue opzioni. Questo porta anche alla mente una terza opzione “ibrida” che stai dimenticando: Guids.

Non preoccuparti delle prestazioni finché non hai un design semplice e corretto che sia in linea con l’argomento che i dati descrivono e si adatta bene all’uso previsto dei dati. Quindi, se emergono problemi di prestazioni, puoi gestirli modificando il sistema.

In questo caso, è quasi sempre meglio andare con una stringa come una chiave primaria naturale, in modo che tu possa fidarti di essa. Non preoccuparti se si tratta di una stringa, purché la stringa sia ragionevolmente breve, dì circa 25 caratteri al massimo. Non pagherai un grande prezzo in termini di prestazioni.

Le persone di inserimento dati o le origini dati automatiche forniscono sempre un valore per la presunta chiave naturale o talvolta vengono omesse? È occasionalmente sbagliato nei dati di input? In tal caso, in che modo vengono rilevati e corretti gli errori?

I programmatori e gli utenti interattivi che specificano le query sono in grado di utilizzare la chiave naturale per ottenere quello che vogliono?

Se non ti puoi fidare della chiave naturale, inventa un surrogato. Se inventi un surrogato, potresti anche inventare un intero. Quindi devi preoccuparti di hide il surrogato alla comunità degli utenti. Alcuni sviluppatori che non hanno nascosto la chiave surrogata sono venuti a pentirsene.

Sì, ma se non si prevede di avere milioni di righe, non si utilizza una chiave basata su stringhe perché è più lenta di solito è “ottimizzazione prematura”. Dopotutto, le stringhe sono memorizzate come numeri grandi mentre i tasti numerici sono solitamente memorizzati come numeri più piccoli.

Una cosa da tenere a mente, però, è se si hanno indici cluster su una qualsiasi chiave e si stanno facendo un numero elevato di inserti non sequenziali nell’indice. Ogni riga scritta farà riscrivere l’indice. se stai facendo inserimenti in batch, questo può davvero rallentare il processo.

Gli indici implicano molti confronti.

In genere, le stringhe sono più lunghe degli interi e le regole di confronto possono essere applicate per il confronto, quindi confrontare le stringhe è in genere un’attività più intensiva dal punto di vista del confronto rispetto ai numeri interi.

A volte, però, è più veloce usare una stringa come chiave primaria piuttosto che creare un join aggiuntivo con una string to numerical id tabella string to numerical id .

Due motivi per utilizzare numeri interi per le colonne PK:

  1. Possiamo impostare l’identity framework per il campo intero che è incrementato automaticamente.

  2. Quando creiamo PK, il db crea un indice (Cluster o Non Cluster) che ordina i dati prima che siano memorizzati nella tabella. Utilizzando un’identity framework su un PK, l’ottimizzatore non deve controllare l’ordinamento prima di salvare un record. Questo migliora le prestazioni su grandi tavoli.

Qual è la tua ragione per avere una stringa come chiave primaria?

Vorrei semplicemente impostare la chiave primaria su un campo intero incrementale automatico e inserire un indice nel campo stringa.

In questo modo, se esegui ricerche sul tavolo, dovrebbero essere relativamente veloci e tutti i tuoi join e le normali ricerche non saranno influenzati dalla loro velocità.

Puoi anche controllare la quantità del campo stringa che viene indicizzato. In altre parole, puoi dire “indicizza solo i primi 5 caratteri” se pensi che sarà sufficiente. O se i tuoi dati possono essere relativamente simili, puoi indicizzare l’intero campo.

Dal punto di vista delle prestazioni – Yes string (PK) rallenterà le prestazioni rispetto alle prestazioni ottenute utilizzando un numero intero (PK), in cui PK —> Chiave primaria.

Dal punto di vista del requisito – Anche se questa non è una parte della tua domanda, vorrei ancora menzionare. Quando gestiamo dati enormi su tabelle diverse, generalmente cerchiamo il probabile insieme di chiavi che possono essere impostate per una determinata tabella. Ciò è principalmente dovuto al fatto che ci sono molte tabelle e che per lo più ciascuna o alcune tabelle sono correlate all’altra attraverso una relazione (un concetto di chiave esterna). Pertanto, non è ansible scegliere sempre un numero intero come chiave primaria, piuttosto la combinazione di 3, 4 o 5 attributi come chiave primaria per tali tabelle. E quelle chiavi possono essere usate come chiave straniera quando vorremmo mettere in relazione i record con qualche altra tabella. Ciò rende utile correlare i record su tabelle diverse quando richiesto.

Pertanto per l’utilizzo ottimale: creiamo sempre una combinazione di 1 o 2 numeri interi con 1 o 2 attributi di stringa, ma di nuovo solo se necessario.

Ci potrebbe essere un grosso malinteso relativo alla stringa nel database. Quasi tutti hanno pensato che la rappresentazione del database dei numeri sia più compatta rispetto alle stringhe. Pensano che nei numeri db-s siano rappresentati come nella memoria. Ma non è vero. Nella maggior parte dei casi la rappresentazione numerica è più vicina a Una stringa come la rappresentazione dell’altro.

La velocità di utilizzo del numero o della stringa dipende più dall’indicizzazione del tipo stesso.

Per impostazione predefinita, ASPNetUserIds ha 128 stringhe di caratteri e le prestazioni vanno bene.

Se la chiave deve essere unica nella tabella, dovrebbe essere la chiave. Ecco perché;

chiave stringa primaria = Corrette relazioni DB, 1 chiave stringa (principale) e 1 stringa indice (principale).

L’altra opzione è una tipica chiave int, ma se la stringa HAS è univoca è comunque necessario aggiungere un indice a causa di query non-stop per convalidare o verificare che sia univoco.

Quindi usando una chiave di id quadro int = Relazioni DB errate, 1 chiave int (primaria), 1 indice int (primario), probabilmente una stringa unica Indice, e manualmente dovendo convalidare la stessa stringa non esiste (qualcosa come un controllo sql forse ).

Per ottenere prestazioni migliori utilizzando un int su una stringa per la chiave primaria, quando la stringa deve essere unica, dovrebbe essere una situazione molto strana. Ho sempre preferito usare le chiavi di stringa. E come buona regola, non denormalizzare un database finché non hai bisogno di farlo.