Je suis en train de mettre en œuvre Personnalisé AspnetMembership à l'aide de EF 4.0
Y a-t-il une raison pour laquelle je devrais utiliser GUID comme clé primaire dans les tables utilisateur?
Aussi loin que je connaisse INT en tant que PK sur SQL Server plus performé que les chaînes.
et int est plus facile à parcourir. En outre, pour le but de la sécurité si je dois passer n'importe quel identifiant Int quelque part E.g dans l'URL, je peux le crypter en quelque sorte et le transmettre comme une chaîne sans probs.
Mais si je veux utiliser le GUID généré automatiquement sur le côté SQL Server à l'aide de EF 4.0, j'ai besoin de faire ce truc http://leeduumond.com/blog/us-u-guid-as-an-entitykey-inentity-Framework-4/
Je ne peux voir aucun cas pourquoi je devrais utiliser le GUID comme PK, peut être un seul système si le système aura des millions d'utilisateurs de millions, mais aussi théoriquement, GUID pourrait être dupliqué de temps en temps n'est pas vrai?
Quoi qu'il en soit, la taille de l'int32 est de 2 147,483,647, il est à peu près même pour un système très très grand, mais si ce nombre n'est toujours pas suffisant, je peux aller avec INT64, dans ce cas, je pourrais avoir 9,223,372.036.854.775.807 ROUILES. À peu près hein?
D'une autre main, M $ en utilisant des GUIDS comme PK dans la mise en œuvre de l'ASPnetMembership. [aspnetdb]. [ASPNET_USERS] -> PK UserID Type Unicalidentifier,
devrait être des raisons / explications pour lesquelles le faisait ?!
Peut-être que quelqu'un a des idées / une expérience à ce sujet?
3 Réponses :
Je serais d'accord à 100% avec vous - en utilisant un GUIDS peut sembler être un choix naturel pour votre clé principale - et si vous le devez vraiment, vous pouvez probablement continuer à l'utiliser pour la clé primaire de la table. Ce que je recommandais vivement à ne pas faire utilise la colonne GUID comme clé de clustering , laquelle SQL Server effectue par défaut, à moins que vous ne le dissiez spécifiquement de ne pas.
Vous devez vraiment garder deux problèmes:
1) La clé primaire 2) La touche de clustering Par défaut, la clé principale d'une table SQL Server est également utilisée comme clé de clustering - mais cela n'a pas besoin d'être de cette façon! J'ai personnellement vu des gains de performances massives lors de la rupture de la clé primaire / clustée principale basée sur le guid précédent en deux touches distinctes - la clé principale (logique) du GUID et de la clé de clustering (commande) sur une identité intégrée distincte (1, 1) colonne.
comme Kimberly Tripp - la reine de l'indexation - et d'autres ont déclaré beaucoup de fois - un GUID, car la clé de clustering n'est pas optimale, car elle entraînera une fragmentation massive de page et d'index et en général Performance.
oui, je sais - il y a Ensuite, il y a un autre problème à considérer: la clé de clustering sur une table sera ajoutée à chaque entrée de chaque index non clusterné de votre table. Ainsi, vous voulez vraiment être aussi petit que possible. . En règle générale, un INT avec 2 milliards de lignes devrait être suffisant pour la grande majorité des tableaux - et comparé à un guid comme clé de clustering, vous pouvez vous épargner des centaines de mégaoctets de stockage sur disque et dans la mémoire du serveur.
Calcul rapide - Utiliser Int contre le GUID en tant que clé principale et clustering:
Total: 25 Mo vs. 106 Mo - Et c'est juste sur une seule table!
Un peu plus de nourriture pour la pensée - Excellentes choses de Kimberly Tripp - Lisez-la, lisez-la à nouveau, digestez-la! C'est l'évangile d'indexation SQL Server, vraiment.
int Identity est beaucoup mieux!
nouvelle suite () dans SQL Server 2005 et up - mais même ce n'est pas vraiment et totalement séquentiel et souffre donc également des mêmes problèmes que le GUID - juste un peu moins en évidence donc.
aller avec le pk int. Voir l'article de Kimberly L. Tripp's: GUIDS comme touches primaires et / ou la clé de clustering
Jusqu'à ce que l'entité cadre introduit tout concept de lots il n'y a aucune raison de ne pas utiliser l'identité int. GUID n'est utile que lorsque vous souhaitez définir l'ID du nouvel enregistrement sur le client.
Quelques opinions blog.sqlauthority. COM / 2010/04/28 / ...
Voici ma question connexe sur GUID PK vs int PK Performance Stackoverflow.com/questions/4600918/...