Discussion :

[Nadinette]

Salut,

J'ai généré les tables nécessaires à ASP.net Identity dans ma base de données SQL Server.
J'ai eu ces alertes :

Avertissement*! La longueur de clé maximale est 900*octets. L'index 'PK_AspNetUserLogins' a une longueur maximale de 1800*octets. Dans certains cas, la combinaison de valeurs élevées entraînera l'échec de l'opération d'insertion/mise à jour.
Avertissement*! La longueur de clé maximale est 900*octets. L'index 'PK_AspNetUserRoles' a une longueur maximale de 1800*octets. Dans certains cas, la combinaison de valeurs élevées entraînera l'échec de l'opération d'insertion/mise à jour.

J'ai été étonnée de voir des PK NVARCHAR 450

C'est possible de mettre des ID Identity 1,1 à la place sans avoir à repondre les librairies de sécurité ?

Merci

[DotNetMatt]

Ce ne sont que des avertissements donc il n'y a rien d'inquiétant. Mais en effet on peut se poser la question du pourquoi avoir des clés en NVARCHAR(450). La raison est pûrement technique.

L'ID d'un utilisateur est une clé surrogée (surrogate key). Donc elle doit répondre aux caractéristiques suivantes :

- la valeur est unique, pour un système entier, et n'est donc jamais réutilisée
- la valeur est générée par le système
- la valeur n'est pas manipulable par l'utilisateur ou l'application
- La valeur n'a aucune signification particulière (elle n'est pas liée aux données, en aucune manière)
- la valeur n'est pas visible par l'utilisateur ou l'application
- la valeur n'est pas composée de valeurs provenant de différents domaines applicatifs

source

Donc Microsoft a fait le choix d'utiliser un Guid, qui n'est autre qu'un entier de 16 bytes et de le stocker en NVARCHAR. Ils auraient aussi pu le stocker en UNIQUEIDENTIFIER, peut-être que ca n'a pas été fait pour des raisons de compatibilié...

Il est possible de changer cela pour utiliser un INT au lieu d'un Guid par exemple, en définissant ton propre IdentityUer : Change Primary Key for Users in ASP.NET Identity. Je ne suis pas sûr qu'il soit possible d'ajouter la propriété IDENTITY par contre...

[Nadinette]

Merci, des fois je me demande si les développeurs ne sont pas tous tombés sur la tête tellement ça devient compliqué de coder alors qu'avant c'était si facile...
Dans l'avertissement, ça dit quand même : Dans certains cas, la combinaison de valeurs élevées entraînera l'échec de l'opération d'insertion/mise à jour.
Du coup, ça me fait peur car j'imagine, après 8 ou 9 mois de boulot t'as tout bien fait, tu déploies dans le SQL Serveur de la boite et lorsque tu crées le premier utilisateur, t'as un message du style:
On t'avais prévenu que ça n’insérerait pas !

Peut-être faut-il prévoir de changer un paramètre dans SQL Server 2014 (dans mon cas) pour ne plus avoir ce warning, non ?

[DotNetMatt]

Ben ASP.NET Identity est beaucoup plus complet que Membership donc forcément c'est un peu plus compliqué à utiliser. Aujourd'hui tu peux gérer ton identification de plein de manières différentes, directement sur ton serveur, via des services tierces comme Facebook, Twitter, etc. via du SSO, via des certificats... Avant il fallait combiner Membership, WIF et d'autres frameworks de ce type. ASP.NET Identity rassemble tout ca et rationalise le tout autour des protocoles d'aujourd'hui (OAuth, OpenId, etc.).

Sinon pour la PK en principe il n'y a rien à faire, tu peux l'ignorer. Je pense que ce message apparait car il n'est pas courant d'avoir des clés primaires (PK) de type NVARCHAR. Donc le système te prévient juste qu'il y a une limite de taille.

Dans mes projets en général je switch vers un type Guid qui est stocké sous forme de UNIQUEIDENTIFIER dans SQL Server, car ensuite c'est plus simple et plus performant pour les jointures. Mais il n'y a rien d'obligatoire à faire cela si tu ne veux pas te lancer dans la personnalisation d'ASP.NET Identity...

[Nadinette]

Je ne suis pas certaine d'avoir le temps et le niveau pour me lancer dans ce genre de trucs...
Merci du conseil.