Selezione di una chiave primaria appropriata per un ambiente distribuito

Per tabelle interessate dalla sincronizzazione incrementale, Sync Framework richiede che ogni riga venga identificata in modo univoco. Non richiesto per la sincronizzazione degli snapshot client e server. Le righe vengono in genere identificate da una chiave primaria definita nel database peer o server. Negli ambienti distribuiti è necessario prestare particolare attenzione nella selezione del tipo di colonna da utilizzare come chiave primaria. Le chiavi primarie devono essere univoche in tutti i nodi e non devono essere riutilizzate. Se una riga viene eliminata, la relativa chiave primaria non deve essere utilizzata per un'altra riga. Se una chiave primaria viene utilizzata da più di un nodo, può verificarsi una collisione di chiave primaria. Ciò si verifica in qualsiasi tipo di ambiente distribuito e non si tratta di un limite di Sync Framework. In questo argomento vengono descritte le diverse scelte disponibili per le chiavi primarie e la relativa adeguatezza per gli ambienti distribuiti.

Colonne a incremento automatico (Identity)

I database architect spesso selezionano una colonna a incremento automatico come chiave primaria. Questa proprietà a incremento automatico (la proprietà IDENTITY in SQL Server) genera un nuovo valore per ogni record inserito in una tabella. Questo nuovo valore viene generato aumentando o riducendo il valore corrente (il valore di inizializzazione) di un valore fisso (l'incremento) e assegnando il risultato alla riga inserita. Le colonne a incremento automatico utilizzano in genere tipi di dati compatti, ad esempio valori integer. Questi valori possono determinare un indice cluster più compatto, join più efficienti e un numero inferiore di IO quando vengono eseguite query nella tabella sottostante.

Tuttavia, poiché il valore di inizializzazione e le proprietà di incremento sono fissi e possono essere selezionati da un numero finito di valori possibili, la probabilità di una collisione di chiave primaria è molto elevata. Questo tipo di chiave è indicato per scenari di memorizzazione dei dati nella cache di solo download. In questi scenari il server o un peer designato dovrebbe essere il solo nodo che genera nuovi valori di chiave primaria. Di conseguenza, vi è la garanzia che questi valori siano univoci in tutti i nodi della topologia. Le colonne a incremento automatico sono inoltre indicate per scenari bidirezionali e di solo caricamento se le operazioni di inserimento vengono eseguite in un solo nodo. In questi scenari le operazioni di inserimento si verificano in genere solo nel server o in un peer designato, mentre le operazioni di aggiornamento e possibilmente quelle di eliminazione si verificano in uno o più client. Se le operazioni di inserimento sono richieste in più nodi, è necessario seguire uno degli altri metodi descritti più avanti in questo argomento.

GUID

L'utilizzo di un GUID (una colonna uniqueidentifier in SQL Server) come chiave primaria garantisce l'univocità in tutti i nodi ed elimina le collisioni di chiave primaria che possono verificarsi con le colonne a incremento automatico. L'utilizzo di un GUID nella chiave primaria comporta tuttavia le seguenti conseguenze:

• Il tipo di dati di grandi dimensioni (16 byte) aumenta le dimensioni dell'indice cluster, fatto che può influire negativamente su operazioni comuni, ad esempio i join.

• La generazione non ordinata di GUID causa l'inserimento di righe in posizioni casuali dell'indice cluster. Questo può a sua volta determinare un indice cluster frammentato che può influire negativamente sull'I/O necessario per eseguire query nella tabella sottostante.

  In SQL Server 2005 e versioni successive è possibile utilizzare la funzione NEWSEQUENTIALID() per generare GUID in un ordine sequenziale allo scopo di eliminare questa frammentazione.

Chiavi che includono un identificatore di nodo

Secondo questo approccio, viene utilizzata una chiave che combina un valore univoco nel nodo server o client con un valore univoco nella topologia. Nella sincronizzazione client e server, ad esempio, è possibile utilizzare una colonna a incremento automatico (univoca nel nodo) combinata con una colonna in cui è archiviato un hash dell'ID assegnato a ogni client da Sync Framework. (Si tratta della proprietà ClientId univoca nella topologia). In seguito verrà creata una chiave primaria composta con queste due colonne. In alternativa, è possibile sviluppare un sistema per generare valori per ogni riga inserita in modo da poter includere l'ID riga e l'ID client in una colonna.

Chiavi naturali

Con questa strategia, non viene utilizzato alcun tipo di chiave prodotta, ma viene invece utilizzata una chiave business per identificare i record in modo univoco. Ad esempio, in una tabella utilizzata per archiviare informazioni sui clienti potrebbe essere utilizzata la colonna del numero di previdenza sociale come chiave primaria anziché una colonna Identity. L'inconveniente di questo approccio è che la chiave primaria potrebbe assumere dimensioni eccessive se è necessaria più di una colonna per identificare un record in modo univoco. Questa chiave composta deve inoltre essere propagata ad altre tabelle per supportare una o più relazioni di chiave esterna. Queste relazioni, a loro volta, influiscono negativamente sulle prestazioni dei join.

Inserimento online

Se nessuna delle soluzioni precedenti risulta appropriata e lo scenario richiede solo alcune operazioni di inserimento nel client, le righe potrebbero essere inserite direttamente nel server. Le nuove righe verranno quindi scaricate e inserite nel client durante la sincronizzazione successiva. Poiché i valori di chiave primaria vengono generati nel server, non si verificheranno collisioni di chiave primaria.

Vedere anche

Concetti

Considerazioni per la progettazione e la distribuzione di applicazioni