Jimmy Nilsson discute de son concept GUID ici . Ce concept est populaire dans NHibernate, entre autres cercles, pour sa prétendue valeur de performance sur les GUID standard qui sont généralement beaucoup plus aléatoires.
Cependant, dans les tests, cela ne semble pas être le cas. Est-ce que je manque quelque chose? P>
Cas d'essai: P>
J'ai une table appelée Temp (pas une table Temp, juste une table nommée "Temp") avec 585 000 rangées. J'ai une nouvelle table appelée codes et souhaite copier toutes les valeurs de code 585 000 de la table TEMP sur la table des codes. Le test SQL SQL I exécuté était la suivante: p>
set statistics time on;
truncate table codes;
DBCC DBREINDEX ('codes', '', 90);
insert into codes (codeid, codevalue)
select newid(), codevalue from temp
truncate table codes;
DBCC DBREINDEX ('codes', '', 90);
insert into codes (codeid, codevalue)
select CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER), codevalue from temp
3 Réponses :
Je suggérerais de ne pas voir l'avantage de la commande car la table cible n'a pas de pk. Donc, c'est la conversion sur le dessus que vous voyez. S'il a un PK, les lignes 585K doivent toujours être triées sur insertion. Comment SQL sait-il qu'il est semi-trié?
Maintenant, s'il s'agissait de 5 850 x inserts de rangée, vous pouvez voir des avantages car les nouvelles lignes iront "à la fin" non "au milieu", donc réduisant ainsi la page de page et les frais généraux.
J'irais plus loin et dis dire que l'article est daté de 2002 et est pour SQL 2000 et a été dépassé par la vraie vie.
dans SQL Server 2005 Nous avons des GUDS séquentiels pour permettre aux GUDS strictement monotoniques de résoudre certains problèmes. Le GUID en tant que PK a été fait ici aussi: Exemple récent: int vs Identifiant unique pour le champ ID dans la base de données avec des liens 3ème partie.
Si un orje dicte le guid comme une PK plutôt qu'une clé de substitution intégrée naturelle ou standard, c'est une grave limitation de l'orj. Et un cas de la queue du client remuant le chien de base de données.
Votre code pour générer de nouveaux GUID n'est pas correct. Pour chaque ligne, il crée un nombre très différent (vous appelez NeufID () pour chaque ligne). Vous devez garder la majeure partie du GUID.
Le codeid est la clé de la table, il faut donc nécessairement être différent. Si vous envisagez du guid de peigne, vous devez alors avoir la première partie aléatoire pour empêcher les collisions clés pour les insertions qui sont toutes dans la résolution de la minuterie (ce qui correspond à 300 ms ou plus?). L'ordre de tri des GUIDS SQL passe par les 6 derniers éléments en premier, de sorte que ceux-ci en tant que nombre ascendant généré à partir de DateTime conservent l'ordre des entrées dans l'index.
I Deuxièmement que vous ne verrez que des différences que lorsque vous avez des index (PK, FK ou d'autres types d'index, regroupés ou non clusterés) sur le GUID Colume, car le coût du GUID standard par rapport au GUID NEWGUID ou WRUC est dû au coût élevé de la réchéralisation des données d'index chaque fois qu'un insert est effectué.
voir Ma question dans lequel je corrobore cela avec des données de vie réelles de SQL Server et Oracle.
Est-ce que ma réponse ou une réponse satisfait à votre question?
@Chris: GBN est-il correct?