Discussion :

[Garhein]

Bonjour,

Je souhaiterai savoir si toutes les tables d'une base de données, possédant toutes une colonne IDENTITY, peuvent partager le même auto increment et non pas un auto increment par table ?

Si oui, est-il possible de récupérer ce futur identifiant avant l'insertion d'une nouvelle ligne ? Je suppose que oui mais que l'on a aucune certitude que ce soit cet identifiant qui soit utilisé lors de l'insertion (si pas exemple, un autre utilisateur insère une valeur entre temps). Il est donc recommandé de récupérer cet valeur après l'insertion de l'enregistrement.

Je connais le système des séquences mais cela oblige à lui demander la prochaine valeur pour l'insérer dans mes nouveaux enregistrements, tandis qu'un auto increment est automatique.


Merci d'avance pour vos retours.

[al1_24]

Et pourquoi pas en plaçant un appel à la séquence dans un trigger before insert ?

[Garhein]

Oui, ça peut être une solution.

Tu me confirmes donc que seules les séquences peuvent me permettre d'avoir des identifiants globaux ?

[SQLpro]

non, les uniqueidentifier aussi. Mais c'est pas conseillé.

De plus pour des raisons de performances l'usage d'une seule séquence pour toutes les tables est d'une imbécilité crasse !

Essayez de comprendre pourquoi !

A +

[Garhein]

Bonjour,

Je sais qu'il n'est pas conseillé d'avoir une seule séquence pour toutes les tables (pour des soucis d'indexation par exemple ?). Cependant, on ne m'a pas laissé le choix.

Il aurait été plus correct d'éviter d'insinuer que je suis un imbécile et d'expliquer clairement les raisons qui font que cela n'est pas recommandé et pourquoi les uniqueidentifier ne le sont pas non plus.

Je vous remercie néanmoins de votre réponse.

[SQLpro]

Il suffit de chercher un peu, notamment dans ce site. Ce sera plus écologique que de reposter 545336154135454 les mêmes réponses aux mêmes délires !

A +

[Garhein]

C'est sur que des réponses de ce genre aident beaucoup les nouveaux utilisateurs de SQL Server comme moi...

Bref, j'ai compris. Je vais me débrouiller tout seul (comme je l'ai toujours fait) et ne compterai plus sur la communauté.

Merci et adieu !

[aieeeuuuuu]

Bonjour,

uniqueidentifier est mauvais pour une clef primaire car d'une part cela fait 16 octets (contre 4 pour un INT par exemple), et d'autres part, ce n'est pas séquentiel.

Vous aurez donc des index plus gros, et plus fragmentés qu'avec un INT/IDENTITY.

Si vous nous exposiez plus concrètement votre contexte et votre besoin, on pourrait peut-être vous aider plus.

[Donpi]

Ça me rappelle un de mes premier projet ou des données étaient rentrer sur des machines nomades sans aucune possibilité de connexion.

Nous avions du mettre en place un système de réservation d'ID pour éviter les les doublons et les erreurs d’intégrité.
Pour le coup nous avions une seule séquence d'id pour la 20aine de tables concernées.

ça marchait plutôt bien compte tenu de la technologie utilisée a l'époque.

Bref, tout ça pour dire que parfois on a pas le choix.
Courage a+

[Garhein]

Bonjour,

uniqueidentifier est mauvais pour une clef primaire car d'une part cela fait 16 octets (contre 4 pour un INT par exemple), et d'autres part, ce n'est pas séquentiel.

Vous aurez donc des index plus gros, et plus fragmentés qu'avec un INT/IDENTITY.

Si vous nous exposiez plus concrètement votre contexte et votre besoin, on pourrait peut-être vous aider plus.

Merci pour ces précisions sur les uniqueidentifier.
Mon besoin est assez simple : il me faut une seule séquence d'identifiant pour toutes les tables, et non pas une séquence par table (ce qui aurait été géré via une colonne IDENTITY).

Ça me rappelle un de mes premier projet ou des données étaient rentrer sur des machines nomades sans aucune possibilité de connexion.

Nous avions du mettre en place un système de réservation d'ID pour éviter les les doublons et les erreurs d’intégrité.
Pour le coup nous avions une seule séquence d'id pour la 20aine de tables concernées.

ça marchait plutôt bien compte tenu de la technologie utilisée a l'époque.

Bref, tout ça pour dire que parfois on a pas le choix.
Courage a+

Effectivement, parfois on a pas le choix et l'on doit faire avec les demandes qui nous sont faites.

---

Merci à vous deux pour vos réponses constructives.

[aieeeuuuuu]

Mon besoin est assez simple : il me faut une seule séquence d'identifiant pour toutes les tables, et non pas une séquence par table

ça ce n'est pas un besoin, c'est une solution envisagée pour répondre au besoin...
Si on comprenait mieux la raison qui vous pousse à vouloir faire ça, on pourrait peut être vous proposer des alternatives.

Sinon, utilisez effectivement uniqueidentifier si les performances ne sont pas un besoin majeur.