Meilleur type de données clé primaire pour Linq à SQL
je commence un nouveau projet avec SqlServer et Linq à Sql.
Quel type de données serait préférable pour les clés de substitution dans les tableaux: identity ou uniqueidentifier ?
si j'ai bien compris, identity est généré automatiquement sur insert, alors que uniqueidentifier doit être généré en code (GUID).
y a-t-il des différences de rendement importantes?
par exemple, la valeur identity doit être lue après insertion, de sorte qu'il y ait un déplacement supplémentaire de la base de données après insertion.
Edit:
J'ai trouvé une réponse très détaillée dans une autre question: Tables sans touches primaires . Lire la réponse choisie.
Edit 2:
en ce qui concerne les réponses sur les clés de substitution: j'aime les clés de substitution plus que les clés naturelles. Cette décision étant prise, veuillez ne pas suggérer de reconsidérer la conception de la base de données. Également, s'il vous plaît, ne discutez pas les avantages et les inconvénients des clés naturelles et de substitution.
6 réponses
je suis d'accord avec un commentaire ici que vous devriez concevoir votre structure de base de données indépendamment de votre méthode d'accès aux données. Que ce soit LINQ2SQL ou ADO.NET ou NHibernate, vous obtiendrez le même ensemble d'avantages/problèmes, si votre PK est auto-identification identité ou GUID.
en fait, je ne peux penser qu'à un seul but d'utiliser GUID en faveur de INT comme PK - dans une application très distribuée avec plusieurs bases de données où les données doivent être synchronisées avec un serveur maître etc Même alors, vous pouvez utiliser L'identité avec différents incréments, par exemple L'identité(1,2) pour un serveur DB, L'identité (2, 2) avec le suivant etc [fonctionne uniquement avec un nombre fixe de serveurs DB bien sûr.]
le principal" problème " avec GUID est qu'il prend plus d'espace (16 octets par rapport à 4/8), non seulement comme PK, mais aussi comme partie de n'importe quel indice dans cette table, puisque chaque indice stocke la valeur PK implicitement. Comparer 16 octets va être plus lent aussi (combien? vous devez le mesurer, il ça dépend)
aussi depuis GUID sont aléatoires, vous pouvez obtenir beaucoup de page-splits lors de l'insertion de lignes (bien que je crois qu'il y a une nouvelle fonction dans SQL Server 2005 ou 2008 pour générer des GUID consécutifs) dans une table. Cela seul peut être très coûteux dans un environnement avec beaucoup de plaquettes.
L'un ou l'autre est très bien. Cela dépend de votre conception. UNIQUEIDENTIFIER fonctionnera lorsque vous avez besoin de créer les ID du côté client, ce qui peut parfois être agréable lorsque vous construisez une liste d'objets que vous aurez besoin d'Ajouter/Supprimer/Modifier sur le client avant d'Envoyer à la base de données. C'est aussi mieux si vous devez fusionner des données créées sur des systèmes différents.
Lessont plus petits, donc ils vont probablement être plus rapides, et ils sont beaucoup plus faciles à utiliser quand vous déboguez quelque chose avec vos données parce qu'elles sont plus faciles à discuter.
bref, il n'y a pas de" meilleure " réponse ici. C'est une décision de conception.
Je ne pense pas que ce soit une bonne idée de choisir la clé primaire de votre table basée sur le fait que vous utilisez LINQ-to-SQL. À mon avis, il serait beaucoup mieux d'utiliser la clé primaire est destiné à assurer l'intégrité des données en identifiant une ligne particulière. Integer ou GUID PKs ne vous protègent pas contre les lignes dupliquées dans votre table (à l'exception des colonnes générées automatiquement, bien sûr). Mais là encore, il y a eu un grand débat qui fait rage au sujet des pros et des clés générées automatiquement:)
j'utilise l'identité et soit int ou bigint en fonction de la taille prévue de la table. Je m'attends à ce que LINQ fasse une seule requête qui combine à la fois insert et key read.
uniqueidentifier peut aussi être inséré automatiquement, en définissant la valeur par défaut dans la base de données à NEWID() .
OK, je venais d'écrire un blog sur ce . Je reprends ci-dessous pour le bénéfice des autres.
l'essentiel semble être des commentaires faits sur ado.net blog qui déclarent que le cadre de L'entité est la seule chose qui obtient un temps de développement majeur pour Visual Studio 2010 et Dot Net 4.
nous avons connu ce
ma réponse est-DUH. Nous avons tous connu ce. Microsoft a déclaré publiquement de retour au PDC 2007 que LINQ à SQL était une version à court terme pour SQL Server parce qu'il n'y avait pas D'autre histoire de LINQ à SQL Server. Il ne fonctionne qu'avec SQL Server. Vous ne pouvez pas écrire un LINQ à SQL provider - il n'y a pas de modèle pour cela. C'était une technologie hors service, pas extensible.
Entity Framework = "Fournisseur De 151980920"
le framework Entity est le seul moyen de Microsoft pour construire un fournisseur LINQ. Le cadre de L'entité a il s'est avéré être tout à fait contreversial, mais je pense que c'est en partie dû au fait que LINQ à SQL a une meilleure expérience de programmeur aujourd'hui. Entity Framework attrapera et surpassera LINQ à SQL parce qu'il est l'outil de cartographie ORM/du futur de Microsoft.
je pense que Microsoft a un énorme investissement dans le cadre D'entité avec des fournisseurs tiers comme nous, IBM, Oracle, etc. S'ils veulent des développeurs tiers et des bases de données pour soutenir LINQ ils ont dû avoir un modèle pour écrire à. Le cadre de l'entité est la réponse.
j'ai vu cela venir l'année dernière quand ils ont relesed LINQ à SQL avec VS 2008 et non le EF. Ils n'auraient jamais dû publier une mise en œuvre fermée de quelque chose avec autant de chevauchement. Je sais qu'ils voulaient une base de données relationnelle, mais je pense qu'ils ont dit le mauvais. Maintenant, il ya beaucoup de développeurs sérieusement confus qui viennent nous demander pour notre fournisseur LINQ to SQL. Il n'y en a pas parce qu'on ne peut pas en écrire un.