Discussion :

[xian21]

Bonjour,

Avec SQL Serveur lorsque nous avons un champs autoincremente nous pouvons recuperer sa valeur lors de l'insertion via @@identity.
Existe t il l'equivalent pour recuperer la valeur d'un rowguid suite a insert?

Merci,

[SQLpro]

Absolument pas et il est TRÈS FORTEMENT déconseillé d'utiliser un UNIQUEIDENTIFIER (GUID ou UUID) comme clef primaire des tables !

A +

[playfone]

Je suis très curieux de savoir pourquoi SQLPRO ! Merci d'avance pour l'explication

[Kropernic]

Parce qu'une colonne de type uniqueidentifier est stockée sur un paquet d'octet, je n'ai plus en tête combien mais c'est plus que 4 (espace utilisé pour stocker un int).

Ce qui fait que, pour chaque table référençant cette clef primaire, ça va faire encore autant d'octets "perdus".

En plus, vu que les clefs sont souvent la cible d'opérateur de comparaison, il est beaucoup plus rapide de comparer des données de type int que des données de type uniqueidentifier.

Si mes souvenirs sont bons, à part si vous travaillez sur plusieurs serveurs en "load balancing" et qu'il faut tout centraliser après, pas la peine d'utiliser uniqueidentifier.

[Kropernic]

J'ai finalement retrouvé la place prise pour stockée un uniqueidentifier et c'est 16 octets. Soit 4 fois plus qu'un int et 2 fois qu'un big int.

De plus, voici ce qu'on peut lire sur la page de la MSDN :

The uniqueidentifier data type has the following disadvantages:

• The values are long and obscure. This makes them difficult for users to type correctly, and more difficult for users to remember.
• The values are random and cannot accept any patterns that may make them more meaningful to users.
• There is no way to determine the sequence in which uniqueidentifier values were generated. They are not suited for existing applications that depend on incrementing key values serially.
• At 16 bytes, the uniqueidentifier data type is relatively larger than other data types, such as 4-byte integers. This means indexes that are built using uniqueidentifier keys might be relatively slower than indexes using an int key.

Le 4e point explicite plus en détail ce que je tentais de soulever.

[SQLpro]

Par exemple ans une jointure vous allez devoir faire 16 fois plus de tour dans le processeur en 32 bits qu'avec un simple INT pour calculer une jointure !

En sus la fragmentation des tables est immédiate et très lourde avec un GUID du fait de son "aléatoirité" alors qu'avedc un incrément il n'y a pas de fragmentation vu que c'est en croissance monotone....

A me lire : http://blog.developpez.com/sqlpro/p7...ent_le_verdict

A +