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,
Version imprimable
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,
Absolument pas et il est TRÈS FORTEMENT déconseillé d'utiliser un UNIQUEIDENTIFIER (GUID ou UUID) comme clef primaire des tables !
A +
Je suis très curieux de savoir pourquoi SQLPRO ! Merci d'avance pour l'explication :)
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.
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 :
Citation:
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.
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 +
Merci pour vos réponses rapides et claires :)
Je demande surtout ça car je travail sous Dynamics CRM, qui est entièrement basé sur des PK de type UNIQUEIDENTIFIER ! Étonnant donc...
L'enfer est pavé de bonnes intentions ;)
SAP avait des clefs primaires stockées dans des NVARCHAR(max) (je ne suis plus totalement sûr du max) mais avec juste des entiers dedans...Citation:
Envoyé par playfone
Il y a quelques années nous avons audité une application de gestion de la sécurité sociale pour les handicapés. la base avait été entièrement réalisée avec des PK sur des GUID...
Le serveur a rapidement atteint ses limites et l'hébergeur avait été attaqué par le client final parce que les temps de réponse étaient catastrophique... Jusqu'à ce qu'il fasse appel à nous et que nous remontions la bêtise à la SSII qui avait développée la chose...
Le plus marrant est que cette SSII avaient viré de la boîte la seule personne compétence sur SQL Server (notre ancien président du GUSS - Groupe de Utilisateurs de SQL Server) !
bref, ils ont dû revoir leur copie.... ce qui leu a coûté cher !
A +
Merci, pour vos reponses.
Juste pour informations le rowguid je l'ai deja en base puisque je bosse sur des serveurs avec replication.
Les developpeurs bossent sur une table ou il n'y a pas d'auto increment et du coup ils font un max(id) pour recuperer la valeur de l'id qu'ils veulent creer.
Donc je cherchais une solution simple sans avoir a toucher la structure de la table ni faire de lock pour leur assurer que leur id est unique.
D'ou mon idee de m'appuyer sur le rowguid.
A priori, c'est d'ailleurs possible via un output de le recuperer juste apres l'insert.
C'est effectivement une solution imbécile car non seulement elle peut provoquer des télescopages (deux fois la même valeur) mais elle est par nature totalement contre performante car il faut verrouiller l'intégralité de la table pour calculer un MAX !Citation:
Envoyé par xian21
A partir de là, vous avez même de grande chances d'obtenir des verrous mortels.
Pourquoi ne pas rajouter la propriété IDENTITY aux colonnes déjà clef ? Ce serait le plus efficace et le plus simple !
A +
Mais comment Microsoft justifie-t-il une gestion totale de Dynamics CRM via Guid alors ? C'est quand même fou par rapport à ce que vous en dites !
EDIT : En faite, Dynamics CRM utilise NEWSEQUENTIALID() pour générer ses PK, une utilisation similaire à l'auto-incrément mais pour les Guid si j'ai bien compris.
Pour l'instant c'est refuse par la direction a cause de l'impact sur la replication. (modification de la structure)...Citation:
Envoyé par SQLpro
C'est légèrement mieux, mais pas plus.... Ceci permet d'éviter un peu la fragmentation...Citation:
Envoyé par playfone
A +
Bonjour,
Pour récupérer la valeur du GUID, je ne vois pas d'autre moyen que d'utiliser la clause OUTPUT :
@++ ;)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Oui, merci 8-)