Sélection d'une clé primaire appropriée pour un environnement distribué
Dans Sync Framework, toutes les lignes des tables qui participent à la synchronisation incrémentielle doivent être identifiées de manière unique. Il ne s'agit pas d'une obligation pour la synchronisation par instantané client et serveur. En règle générale, les lignes sont identifiées par une clé primaire qui est définie dans la base de données serveur ou d'homologues. Dans les environnements distribués, vous devez être particulièrement vigilant lorsque vous sélectionnez le type de colonne à utiliser comme clé primaire. Les clés primaires doivent être uniques sur tous les nœuds et ne doivent pas être réutilisées : si une ligne est supprimée, la clé primaire de cette ligne ne doit pas être utilisée pour une autre ligne. Si une clé primaire est utilisée par plusieurs nœuds, une collision de clé primaire peut se produire. Ce problème survient avec tous les types d'environnements distribués ; il ne s'agit pas d'une limitation de Sync Framework. Cette rubrique décrit plusieurs choix que vous pouvez effectuer pour les clés primaires. Elle indique également dans quelle mesure ces choix sont appropriés aux environnements distribués.
Colonnes à incrémentation automatique (Identité)
Les architectes de base de données sélectionnent souvent une colonne à incrémentation automatique qui jouera le rôle de clé primaire. Cette propriété d'incrémentation automatique (propriété IDENTITY dans SQL Server) génère une nouvelle valeur pour chaque enregistrement inséré dans une table. Cette nouvelle valeur est générée en augmentant ou en réduisant la valeur actuelle (la valeur de départ) en fonction d'une valeur fixe (l'incrément) et en affectant le résultat à la ligne qui est insérée. Les colonnes à incrémentation automatique utilisent généralement des types de données compacts, tels que des entiers. Ceci peut entraîner un index cluster plus compact, des jointures plus efficaces et des entrées/sorties moins importantes lorsque la table sous-jacente est interrogée.
Cependant, étant donné que la valeur de départ et les propriétés d'incrément sont fixes et peuvent être sélectionnées à partir d'un nombre infini de valeurs possibles, la probabilité d'une collision de clé primaire est très élevée. Ce type de clé convient aux scénarios de mise en cache des données et de synchronisation par téléchargement uniquement. Dans ces scénarios, le serveur ou un homologue désigné doit être le seul nœud qui génère de nouvelles valeurs de clé primaire. Par conséquent, ces valeurs seront nécessairement uniques sur tous les nœuds de la topologie. Les colonnes à incrémentation automatique sont également adaptées aux scénarios de synchronisation bidirectionnelle et de synchronisation par téléchargement ascendant uniquement si les opérations d'insertion interviennent sur un seul nœud. En principe, les opérations d'insertion interviennent uniquement sur le serveur ou un homologue désigné dans ces scénarios ; les opérations de mise à jour (et éventuellement les opérations de suppression) interviennent sur un ou plusieurs clients. Si vous êtes amené à réaliser des opérations d'insertion sur plusieurs nœuds, vous devez utiliser l'une des méthodes décrites ci-après dans cette rubrique.
GUID
L'utilisation d'un GUID (colonne de type uniqueidentifier dans SQL Server) comme clé primaire garantit l'unicité, quel que soit le nombre de nœuds, et élimine les collisions de clés primaires possibles avec les colonnes à incrémentation automatique. Toutefois, l'utilisation d'un GUID dans la clé primaire entraîne les conséquences suivantes :
Le type de données volumineuses (16 octets) accroît la taille de l'index cluster, ce qui peut affecter les opérations courantes, telles que les jointures.
La génération non ordonnée de GUID provoque l'insertion des lignes à des emplacements aléatoires dans l'index cluster. Ceci peut à son tour provoquer un index cluster fragmenté. Cela peut affecter les entrées/sorties requises pour interroger la table sous-jacente.
Dans SQL Server 2005 et les versions ultérieures, vous pouvez utiliser la fonction NEWSEQUENTIALID() pour générer des GUID dans un ordre séquentiel afin d'éliminer cette fragmentation.
Clés qui incluent un identificateur de nœud
Avec cette méthode, vous utilisez une clé qui associe une valeur unique sur le nœud du serveur ou du client à une valeur qui est unique dans la topologie. Par exemple, dans la synchronisation client et serveur, vous pouvez utiliser une colonne à incrémentation automatique (unique sur le nœud) associée à une colonne qui stocke un hachage de l'ID affecté par Sync Framework à chaque client. (Il s'agit de la propriété ClientId qui est unique dans la topologie.) Vous devez ensuite créer une clé primaire composite qui comporte ces deux colonnes. Il existe une autre méthode qui consiste à créer un système permettant de générer des valeurs pour chaque ligne insérée afin que vous puissiez inclure l'ID de ligne et l'ID de client dans une colonne.
Clés naturelles
Avec cette stratégie, vous n'utilisez pas une clé d'un fabricant mais une clé d'entreprise pour identifier les enregistrements de manière unique. Par exemple, une table qui stocke les informations des clients peut utiliser la colonne de numéro de sécurité sociale comme clé primaire au lieu d'une colonne d'identité. Cette méthode présente un inconvénient : la clé primaire peut devenir volumineuse si plusieurs colonnes sont requises pour identifier un enregistrement de manière unique. Qui plus est, cette clé composée doit être propagée aux autres tables pour prendre en charge une ou plusieurs relations de clé étrangère. Ces relations peuvent à leur tour nuire aux performances des jointures.
Insertion en ligne
Si aucune des solutions précédentes n'est adaptée et que votre scénario requiert simplement quelques opérations d'insertion sur un client, l'application peut être en mesure d'insérer directement ces lignes sur le serveur. Les nouvelles lignes seront téléchargées et insérées sur le client lors de la synchronisation suivante. Étant donné que les valeurs de clés primaires sont générées sur le serveur, aucune collision de clés primaires ne se produira.
Voir aussi
Autres ressources
Considérations sur la conception et le déploiement d'applications