OVH Cloud OVH Cloud

contrainte identity vs. rowguidcol

2 réponses
Avatar
Eric Belhomme
bonjour,

Je suis en pleine conception d'un modèle de DB relationnelle, et je me pose
une question sur la meilleure façon de lier mes tables, a savoir si il vaut
mieux utiliser une colonne de type IDENTITY ou ROWGUIDCOL...

L'aide en ligne de MS SQL me laisse perplexe quant à l'utilisation de l'une
plutot que de l'autre...

Des suggestions ?

--
Rico

2 réponses

Avatar
lionelp
Bonjour,

Le uniqueidentifier est unique "universellement" mais coute en stockage (16
bytes). C'est donc à utiliser dans quelques cas particuliers comme clé
primaire de tables sur plusieurs serveurs sur lesqueles s'appuie une vue
distribuée et on veut s'assurer d'une unicité à travers les différents
serveurs.
L'identity c'est généralement du int (4 bytes).
Il y a quand-même pas mal de chose dans le BOL sur l'uniqueidentifier.

Cordialement,
LionelP


"Eric Belhomme" wrote in message
news:
bonjour,

Je suis en pleine conception d'un modèle de DB relationnelle, et je me


pose
une question sur la meilleure façon de lier mes tables, a savoir si il


vaut
mieux utiliser une colonne de type IDENTITY ou ROWGUIDCOL...

L'aide en ligne de MS SQL me laisse perplexe quant à l'utilisation de


l'une
plutot que de l'autre...

Des suggestions ?

--
Rico


Avatar
Sylvain Lafontaine
Il est beaucoup plus facile d'utiliser IDENTITY plutôt que ROWGUIDCOL.

Ce dernier (ROWGUIDCOL) a été principalement prévu pour les cas de
réplication bi-directionnelle de BDDs entre plusieurs serveurs mais sa
syntaxe d'utilisation très bizarre est carrément frustrante. De plus,
pensez au plaisir que vous allez avoir quand vous aurez à débugger une BDD
utilisant des GUID comme clefs identifiants...

S. L.

"Eric Belhomme" wrote in message
news:
bonjour,

Je suis en pleine conception d'un modèle de DB relationnelle, et je me


pose
une question sur la meilleure façon de lier mes tables, a savoir si il


vaut
mieux utiliser une colonne de type IDENTITY ou ROWGUIDCOL...

L'aide en ligne de MS SQL me laisse perplexe quant à l'utilisation de


l'une
plutot que de l'autre...

Des suggestions ?

--
Rico