Discussion :

[JYves]

Non, ça c'est catastrophique en terme de performances. Ne jamais utiliser les GUID comme clef primaire. De plus la réplication de fusion nécessite l'utilisation des GUID comme tag d'identification des lignes distribuées. Vous allez avoir de sérieux problèmes. Sachez que le mécanisme de calcul des GUID est un mécanisme de niveau Windows et que donc tous les accès concurrent pour insérer de nouvelles lignes vont taper dans le même bout de code, ce qui fait que cela constituera un hot spot indémerdable. De plus les GUID fragmentent les tables de manière catastrophique et vous allez donc passer votre vie à maintenir ces index !
Si vous voulez des performances, la seule chose est d'utiliser des auto incrément de type INT ou BIGINT.
Sachez que ROWGUIDCOL doit être réservé pour des traitements particulier comme le FILESTREAM. SI vous l'utilisez pour votre PK, vous ne pourrez plus utiliser le FILESTREAM !

cf. plus haut : PRIMARY KEY NONCLUSTERED

ça n'a pas de sens! En matière de BD on s'intéresse à la sémantique pas à des informations techniques. Qui vous dite que deux commerciaux ne saisiront pas le même client avec 2 id différents ?

Il est toujours possible de "fusionner" manuellement ces cas rares pour mon projet.

La vous êtes cuit !

Arf, ça fait peur ! Mais pourquoi donc ?

Merci de vos conseils,
JYves

[SQLpro]

cf. plus haut : PRIMARY KEY NONCLUSTERED

SQL Server a été spécialement conçu pour fonctionner au mieux avec des tables conçues de façon clustered... et c'est parfait si les index clstered sont posés sur une seule colonne unique non nulle de petite taille et monotone, ce qui est le cas d'une PK avec identity... Mais si vous n'avez pas besoin de performances, c'est une autre histoire !

Il est toujours possible de "fusionner" manuellement ces cas rares pour mon projet.

Ne vous leurrez pas, ces cas ne seront pas rare !

A +