Conseil: Clés Identité SQL Server vs Identificateur unique lors de l'utilisation d'Entity Framework

Question

Je suis en train de concevoir un système assez complexe. L'une de nos principales préoccupations est la prise en charge de la réplication d'égal à égal de SQL Server. L’idée est de prendre en charge plusieurs nœuds séparés géographiquement.

Une préoccupation secondaire utilise un ORM moderne dans la couche intermédiaire. Notre premier choix a toujours été Entity Framework, principalement parce que les développeurs aiment le travailler. (Ils aiment le support LiNQ.)

Alors voici le problème:

En gardant à l’esprit la réplication entre homologues, j’ai opté pour uniqueidentifier avec la valeur par défaut newsequentialid () pour la clé primaire de chaque table. Cela semblait offrir un bon équilibre entre l’évitement des collisions clés et la réduction de la fragmentation de l’indice.

Cependant, il s'avère que la version actuelle d'Entity Framework a un limitation très étrange : si la colonne de clé d'une entité est un identificateur unique (GUID), il ne peut pas être configuré pour utiliser la valeur par défaut (newsequentialid ()) fournie par la base de données. La couche d'application doit générer le GUID et renseigner la valeur de la clé.

Alors, voici le débat:

1. abandonnez Entity Framework et utilisez un autre ORM:
   • utiliser NHibernate et abandonner le support LiNQ
   • utilisez linq2sql et abandonnez toute prise en charge future (pour ne pas mentionner le fait de vous lier à SQL Server sous DB)
2. abandonner les GUID et utiliser une autre stratégie PK
3. concevoir une méthode pour générer des GUID séquentiels (COMB?) au niveau de la couche d'application

Je suis orienté vers l'option 1 avec linq2sql (mes développeurs aiment vraiment linq2 [stuff]) et 3. C'est principalement parce que je suis un peu ignorant des autres stratégies clés qui prennent en charge le schéma de réplication que nous visons tout en conservant les choses saines du point de vue du développeur.

Toute idée ou opinion serait grandement appréciée.

Answer 1

Une autre option (non disponible au moment de la publication) consiste à effectuer une mise à niveau vers EF 4, qui prend en charge les GUID générés par le serveur.

Answer 2

J'appuie la proposition de Craig - option 4.

Vous pouvez toujours utiliser la colonne GUID, renseignée par le niveau intermédiaire, en tant que clé primaire (c'est une construction logique).

Pour éviter la fragmentation massive d’index (donc: table), utilisez une autre clé (idéalement une colonne INT IDENTITY) en tant que CLUSTERING KEY - c’est une construction de base de données physique, qui PEUT être séparée de la clé primaire.

Par défaut, la clé primaire est la clé de clustering, mais ce n'est pas obligatoirement le cas. En fait, j’ai amélioré les performances et considérablement réduit la fragmentation en ne faisant que cela sur une base de données dont je "hérite". - ajoutez une colonne INT IDENTITY et placez la clé de regroupement sur ce petit INT, qui ne cesse de grandir et qui ne change jamais - fonctionne à merveille!

Marc

Answer 3

Hein? Je pense que vos trois options sont un faux choix. Considérez l'option 4:

  

4) Utilisez Entity Framework avec des GUID non séquentiels , générés par le client.

L'EF ne peut pas voir les GUID générés par le serveur de base de données pour les nouvelles lignes insérées par la structure elle-même , bien sûr, mais vous n'avez pas besoin de générer les GUID sur le serveur de base de données. Vous pouvez les générer sur le client lorsque vous créez vos instances d'entité. L'intérêt d'un GUID est de savoir où vous le générez. En ce qui concerne les GUID générés par une base de données répliquée, l'EF les verra très bien.

Vos GUID côté client ne seront pas séquentiels (utilisez Guid.NewGuid ()), mais ils seront garantis uniques dans le monde entier.

Nous le faisons dans les logiciels d’expédition, de production avec réplication. Cela fonctionne .

Answer 4

Pourquoi ne pas utiliser la colonne d'identité? Si vous effectuez une réplication de fusion, vous pouvez faire en sorte que chaque système démarre à une valeur de départ distincte et fonctionne dans une direction (par exemple, le noeud a commence à 1 et ajoute 1, le noeud b commence à 0 et soustrait un) ...

Answer 5

Vous pouvez utiliser des procédures stockées si vous êtes vraiment bloqué avec NewSequentialID (). Vous pouvez lier les colonnes de résultat de la procédure à la propriété appropriée. Une fois inséré, le GUID généré par SQL sera renvoyé à l'objet.

Malheureusement, vous devez définir des SP pour les trois opérations (insertion, mise à jour, suppression) même si les autres opérations se terminent correctement avec les valeurs par défaut. Vous devez également gérer le code SP et vous assurer qu'il est synchronisé avec votre modèle EF au fur et à mesure que vous apportez des modifications, ce qui pourrait rendre cette option peu attrayante en raison de la surcharge supplémentaire.

Vous trouverez un exemple pas à pas à l'adresse http://blogs.msdn.com/bags/archive/2009/03/12/entity-framework-modeling-action-stored-procedures.aspx qui est plutôt simple à venir.

Answer 6

utilisez newseqid avec votre propre orme (ce n’est pas si difficile) avec linq