Discussion :

[berceker united]

Bonjour,
Je suis pris d'un affreux dilemme. Ayant commencé sur Mysql, je pense avoir trop pris la mauvaise habitude de toujours utiliser un id auto incrémenté. Maintenant je travail sur SQL Server dans ma boite ou là nous utilisons plutôt les GUID généré par nous. Au départ j'étais pas super chaud d'utiliser ce genre de chose mais par la suite je me suis fait. Le seul inconvénient c'est lors des débug ou il est plus facile de retenir un numérique qu'un GUID.
Mais voila, dans un projet ou je dois transférer des données entre deux serveur SQL ayant deux bases de données avec une structure différente. L'un c'est des GUID dont nous avons la maitrise et l'autre son des ID auto incrémenté que nous maitrisons pas.
J'ai un peut galéré pour transférer des données. Car avec les données envoyé sur un table gérant l'auto incrément il faut que je récupère cette id pour faire les autres jointure parce que bien évidemment il y a des contraintes entre les tables.

Bref, je commence à me rendre compte que l'auto incrément peut faciliter un peut les choses mais peut être un vraie piège qui rend un peut la base rigide.
Je voulais donc connaitre les points de vue d'un DBA sur ce sujet.
Merci
______

[Waldar]

Je dirai que dans vos données internes il vaut mieux un ID, dans des données exportables / diffusables il vaut mieux des GUID.

D'ailleurs le moteur de réplication de SQL Server fonctionne avec des GUID.

[berceker united]

Merci pour votre intervention.
Il est vrai que quand c'est en interne je n'ai pas eu de problème mais lorsqu'il s'agit de transfère de données entre base de données ça commence à être la galère surtout s'il y a des interactions entre elle. Mais pourquoi si c'est en interne est il préférable que ça soit des id plutôt que de prendre un GUID ou UUID par défaut ?

[CinePhil]

Je ne vois pas en quoi l'utilisation d'un identifiant auto-incrémenté peut poser problème !
Un identifiant est normalement un numéro anonyme utilisé uniquement par le SGBD dans les clés primaires et les jointures.

L'utilisateur n'a pas à savoir qu'à son login dans la table des utilisateurs correspond l'ID 825 ou 3564. Par contre c'est important pour le SGBD en tant que clé primaire et éventuellement clé étrangère dans d'autres tables.

L'avantage de l'auto-incrément est qu'il est généré automatiquement par MySQL avec l'instruction AUTO_INCREMENT dans le script de création de la table ou avec le type SERIAL lors de la création d'une table PostgreSQL (ce qui entraîne la création d'une séquence et des instructions adéquates pour la table, système beaucoup plus compliqué que le simple AUTO_INCREMENT de MySQL mais bon...).

Je ne sais pas si le GUID est aussi facile à générer et à utiliser que l'ID auto_incrémenté mais ce qui est sûr c'est que la clé primaire est par définition unique et que l'auto_incrémentation répond parfaitement à ce besoin.

[SQLpro]

L'idée d'utiliser un GUID comme clef primaire en lieu et place d'un INT auto incrémente est d'une effrayante stupidité :
1) le calcul du GUID est plus long quoiqu'on en dise qu'un simple autoinc, même s'il existe des techniques minimisant ce calcul (sérialisation de GUID)
2) le stockage d'un GUID nécessite 16 octets soit 4 fois plus qu'un INT, et donc 8 fois plus couteuses en terme de comparaison dans les jointures...
3) la génération des GUID n'est pas monotone au sens mathématique du terme et conduit donc a de la fragmentation d'index immédiatement.
4) la clef de la table est à défaut un index cluster et sa valeur est reprise dans tous les autres index. Ces index sont donc tous 4 fois plus volumineux pour la valeur de clef de retour.
5) il n'y a aucun intérêt à utiliser un tel type de données car je doute qu'un jour vous ayez 2 puissance 128 lignes dans votre table, soit 34028236692093846346337460743177000000 lignes à stocker...

J'ai été confronté dans plusieurs audit de bases de données à des bases pourries par les très mauvaises performances induite par l'utilisation systématique des GUID. Bien entendu cela n'affecte pas les performances des petites bases, mais lorsque le volume des données à traiter commencer à dépasser largement la RAM, c'est à dire quand il est trop tard pour revenir en arrière.
Lisez les articles que j'ai consacré à l'optimisation : http://sqlpro.developpez.com/optimisation/
en particulier, partie 3 page 9

Il est assez évident que cette façon de faire vient de personne n'ayant aucune des connaissances nécessaires pour faire des développements de type bases de données, mais le plus souvent des gens qui pensent objet (c'est à dire traitement unitaire, ce que les bases de données ne font pas !).
Je dois d'ailleurs faire un audit d'une telle application dans les jours qui viennent, et je m'en marre d'avance !

Et pour couronner le tout, voici un test à faire :
http://blog.developpez.com/sqlpro/p7...nt-le-verdict/

A +

[CinePhil]

Ouf ! Je vois que je n'ai rien perdu à ne pas suivre le GUID !

[berceker united]

Personnellement, j'ai pas commencé à l'utiliser mais j'ai été confronté à un problème de conflit de transfère de données entre une base utilisant des GUID et de l'autre un INT auto incrément. Le problème c'est que je ne maitrisais pas l'auto. En gros, lorsque je créais une ligne sur la base utilisant un auto incrément il fallait que je récupère cette id pour effectuer d'autre traitement par rapport à cette id. Cela oblige de faire des traitement ligne par ligne.

Mais lorsque j'utilise ce genre de requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
INSERT INTO [MonServer#1].[MaBase].[User].[MaTable]
SELECT [MesChamps] FROM  [MonServer#2].[MaBase].[User].[MaTable]

Là je ne sais pas ce qu'a créé comme ID le de destination. Je pourrais éventuellement le prédire mais c'est risquer et couteux. Alors que si j'utilisais les GUID que j'ai sur le serveur source et que je l'ai redonne au serveur de destination je réduis mes risques et je sais avec quel ID je peux travailler.

[CinePhil]

Et quelle est l'importance de savoir quel ID a été créé ?

Vous n'allez pas interroger la base avec un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT *
FROM Personnes
WHERE P_Id = 12824

Vous allez plutôt chercher à rapatrier les données d'une personne nommée Jean Dupont :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT *
FROM Personnes
WHERE P_Nom = 'Dupont' AND P_Prenom = 'Jean'

Au passage, vous récupérerez son ID que vous pourrez utiliser ensuite pour faire la liaison avec d'autres tables.

Imaginons que l'utilisateur tape dans son interface un nom et un prénom pour rechercher une personne, la requête ci-dessus va permettre d'afficher sur son écran toutes les personnes nommées Jean Dupont. Ensuite, au vu des autres informations affichées (adresse, date de naissance ou que sais-je ?), l'utilisateur choisit la bonne personne en cliquant par exemple sur une case à cocher à côté du nom et c'est le système qui sait qu'il s'agit de l'ID 12824 et qui va alors afficher toutes les autres informations issues des autres tables (Contrats par exemples) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT *
FROM Contrats
WHERE C_IdPersonne = 12824

Que l'ID soit auto-incrémenté ou un GUID n'a aucune importance !

Par contre, SQLPro a expliqué pourquoi il est préférable d'utiliser un entier auto-incrémenté plutôt qu'un GUID.

[berceker united]

J'ai bien lu les blog de SQLPro et j'ai bien compris les raisons.
Dans mon cas c'est un peut plus compliqué parce que dans l'exemple j'ai fais qu'un simple requête mais en faite ça devient un peut plus compliqué.
Voici un cas.
Admettons que j'ai plusieurs sociétés ayant un parc automobile. Pour x raison je dois transférer les données d'un serveur de base de données à une autre. En sachant que la société peut éventuellement exister sur les deux serveur. L'une des base c'est des GUID et l'autre un auto incrément.
Le problème c'est comment faire pour que les voitures puisse retrouver son propriétaire si je n'ai pas en retour sa clé qui à changé de nature afin de le placer dans le nouveau serveur sans que les contraintes d'intégrité me bloque.
Seul solution c'est de faire une jointure entre les société du serveur source avec les sociétés sur le serveur cible. Oui mais je ne peux pas me baser sur les clés vu que je ne les connais pas mais seulement une référence qui sont pas forcément fiable qui est le nom car ce le seul élément en commun entre les deux.
De cette jointure je peux récupérer l'id généré sur le serveur cible et renvoyé l'information des voitures avec la bonne clé.
J'ai oublié de préciser que j'ai pas le droit de changer la structure du serveur cible.

Dans le cas ou il y aurait eu un GUID ou un ID pas auto incrémenté mais maitrisable j'aurais pu faire un OneShoot directe.

[SQLpro]

1) vous pouvez forcer la saisie d'une valeur de clef même si un auto incrément y a été défini (Voir IDENTITY_INSERT de SQL Server)
2) vous pouvez régler le pas d'insertion et la valeur initiale des auto incrément (IDENTITY(valinitiale, pas)

En conclusion il est simple de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IDENTITY(1, 2)

sur le serveur A, et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IDENTITY(2, 2)

sur le seveur B.
Et si vous avez plus de deux serveurs, il suffit d'augmenter encore la pas et de décaler d'autant les valeurs initiales sur chaque serveurs...

A +

[berceker united]

Merci pour cette info importante
Le seul risque c'est qu'il peut y avoir conflit d'écriture venant d'un autre client à moins de placer volontairement un verrou sur la table pour avoir la main total dessus.