Identity ou UniqueIdentifier (Guid) ?

Je dois être maudit ! Cela fait prés de 3 ans que sur tous les projets sur lesquels j’interviens, le sempiternel troll du Identity vs Guid revient me hanter.

Non, non, non… je ne suis pas un ayatollah de la base de donnée… je n’ai rien contre les GUID ! Mais pourtant j’ai quand même du mal à comprendre pourquoi on a tendance à en coller partout, même quand ca n’a aucun sens… et ca j’ai vraiment du mal…

Mettons notre casquette de dba (je sais… beurk !)

Le Guid c’est le mal (sauf pour la réplication ou l’on n’a pas le choix)… car :

• en production, on a vu plus simple que d’écrire des jointures sur des choses aussi imbitables, et anti-mémorisable que B2F62BF0-5CE0-408c-B749-F37D76AF5629.

• Les perfs sont juste pourries par rapports à celles que l’on obtiendrait avec un int. J’en entends déjà plus d’un ricaner et prêt à me soutenir le contraire….Bien ! Rendez-vous sur ce benchmark, et prenez même 10 minutes pour lancer le test chez vous… c’est flagrant !Ce qui est étonnant, c’est qu’un grand nombre de développeurs, y compris des gens très brillant, passent à côté de ce point… certain m’ont déjà soutenu le contraire… au secours !

Mettons notre casquette de développeur :

Le Guid c’est la meilleure invention depuis le garbage collector… ! Si si je fais mon gloubi-boulga et puis je referme le capot, ca marche à tout les coups… c’est génial le GUID.

Dans une architecture en couche, je peux générer des Id dans ma couche client, associer des entités entre elles… puis :

Si j’ai envie de les persister, pas de soucis et pas d’aller retour avec la le tiers de persistance (base de données), mes identifiants sont à coup sur uniques.

Si j’ai envie d’annuler tout ce que j’ai fais, bah je cache méthodiquement tout sous le tapis (lisez : je laisse travailler le garbage collector).

Tandis qu’un Int en tant qu’identifiant, qu’est ce que c’est embêtant… je crée une entité sur mon client mais tant que je n’ai pas fait d’aller retour avec ma base de donnée, je n’ai aucun moyen de savoir son identifiant…

Vous voulez associer un produit et sa catégorie de produit tout deux nouvellement crées ? Possible, mais on va devoir écrire un peu de code et faire des allers-retours avec la base.

Bref… vu d’en haut l’identity c’est chiant… on est d’accord.

PS : Pour ceux qui me diraient qu’on est pas obligé de faire des applications en couches séparées… bah…. ils ont raison, mais sur un projet un minimum important ca devient vite difficile à maintenir de tout coder dans la form (aussi bien web que win)… faut que vous jetiez un coup d’œil au TDD.

Voila, c’est la que commence à mon sens notre vrai travail. Il nous faut estimer les avantages et les inconvénients des deux approches, et faire un choix entre la performance pure de la base et grosso modo la vitesse de développement de l’application… en ces temps ou le mot d’agilité et dans la bouche de tous, le choix est vite fait… Promis m’sieur y’a quelques temps j’arrivais encore à faire le grand écart…

Bon tout ca c’est bien beau, mais alors quelqu’un pourrait m’expliquer pourquoi il m’arrive de tomber sur des bases qui sont truffées de GUID (seul type de donnée utilisé comme clé primaire des tables) lorsque celles-ci sont attaquées par une application en mode client-serveur ? Franchement, la, ca me dépasse !

Bon, aller pour ceux qui ont réussi à me lire jusqu’ici, voici quelques liens supplémentaires sur le sujet :

Les racines des problèmes que posent les GUID avec les index Clustered

la fonction SQL-SERVER NEWSEQUENTIALID() si on adore les GUID dans SQL et que l’on ne peut s’en passer.

Et le meilleur pour la fin, je vous laisse réfléchir sur la phrase suivante trouvée dans la MSDN :

Consider using the IDENTITY property when global uniqueness is not required, or when having a serially incrementing key is preferred.

Evidemment, si certain d’entre vous on envie de troller sur le sujet… les commentaires sont fait pour ca :)