Utilizzo e gestione di colonne identity in SQL Server
Pagina 1 di 3
Quando si progetta un database per supportare applicazioni è fondamentale considerare come gestire le chiavi primarie. Esistono a tal proposito almeno due scuole di pensiero: una che sostiene che la cosa giusta da fare sia quella di utilizzare le cosiddette chiavi surrogate (cioè che non si basano su dati reali) e l’altra che sostiene che occorre utilizzare invece dati reali come valori delle chiavi. Vi è poi una strada intermedia che consiste nell’ utilizzare all’interno di un database entrambe le suddette soluzioni, a seconda dei relativi pro e contro (che analizzeremo a breve).
Quando si progetta una tabella generalmente essa contiene una o più colonne che costituiscono la sua chiave primaria. Come ben sappiamo una chiave primaria di una tabella è un valore (o una combinazione di valori) che identifica univocamente ogni riga. Come accennato in precedenza se una chiave è costituita da valori reali si parla di chiave naturale, mentre se ad esempio la chiave viene generata ogni volta che inserisce una riga in tabella allora si parla di chiave surrogata. Una chiave surrogata è generalmente un valore numerico e spesso in SQL Server le colonne di questo tipo sono quelle di tipo identity, di cui parleremo in seguito.
Una chiave naturale è costituita da dati reali, dati cioè che hanno una relazione con i valori presenti nelle altre colonne della riga (ad esempio il codice fiscale di un individuo in una tabella Clienti che contiene anche le sue generalità). Anche una chiave surrogata identifica univocamente una riga di una tabella ma il suo valore non ha relazioni con gli altri valori della riga ed esso viene semplicemente generato e memorizzato.
Analizziamo i pro e i contro dei due tipi di chiavi cominciando da quelle surrogate:
I PRO
- Una chiave surrogata non ha relazioni con gli altri dati della riga
- Se è necessario effettuare modifiche al database che riguardano l’aggiornamento delle chiavi naturali questo può essere effettuato facilmente senza compromettere le relazioni di chiave esterna, se quest’ultime non si basano su chiavi naturali ma su una surrogate
- Le chiavi surrogate sono solitamente di valore intero e quindi richiedono solo quattro byte per la memorizzazione rendendo in questo modo le strutture di indicizzazione più piccole e performanti (cosa che influenza positivamente le operazioni di join)
I CONTRO
- Se le tabelle collegate in chiave esterna sono legate con un valore surrogato ad una tabella principale, per ottenere i valori reali di collegamento tra le varie tabelle è necessario effettuare operazioni di join
- Le chiave surrogate non sono molto utili se si ricercano particolari informazioni, poichè i valori in esse contenuti non hanno un significato reale
Per quanto riguarda le chiavi naturali:
I PRO
- Si prestano meglio alle ricerche perchè i valori hanno un significato reale
- Richiedono meno operazioni di join per ottenere i valori delle chiavi perchè essi sono contenuti in tutte le tabelle coinvolte nei join
- Si prestano meglio alle ricerche perchè i valori hanno un significato reale
I CONTRO
- E’ molto più complicato aggiornarle, soprattutto se le relazioni di chiave esterna con altre tabelle si basano su di esse
- Gli indici assumono dimensioni maggiori poichè le chiavi naturali tipicamente richiedono più byte per la memorizzazione
- I join basati su chiavi naturali composite (che spesso includono dati di tipo stringa) sono più lenti rispetto a quelli effettuati con chiavi surrogate
