Discussion :

[Higgins]

Bonjour,

Je cherche une alternative aux GUID. J'ai plusieurs bases similaires avec des données qui doivent pouvoir être échangées entre les différentes tables. Pour identifier chaque enregistrement de manière unique, j'ai pensé utiliser des clés (int ou bigint) sur deux colonnes: une fixe pour l'ensemble de la base de données que j'attribue pour chaque nouvelle base et une autre en autoincrement. Le problème est que j'ai besoin d'identifier, en plus, sur chaque base l'utilisateur(ou groupe d'utilisateur) à qui a créé les données.
Je me retrouverais alors avec une clé sur 3 colonnes pour chaque table. J'ai l'impression que ce sera lourd. Est-ce la meilleure solution ? Est-ce la seule ? Comment feriez-vous ?

[SQLpro]

Sur chaque serveur/utilisateur, mettez un autoincrément avec un pas et une graine décalée.
Par exemple : 250 serveurs
Prenez un BIGINT et :

• sur le serveur 1 faites toutes vos tables en IDENTITY(1, 250)
• sur le serveur 2 faites toutes vos tables en IDENTITY(2, 250)
• sur le serveur 3 faites toutes vos tables en IDENTITY(3, 250)

...
Pour savoir d'où vient la ligne :
ID % 250 vous donnera le N° du serveur.

A +

[Higgins]

Merci pour votre réponse.
J'ai peur d'avoir un problème de mise "en pratique". Chaque base de données est une extraction de la base d'origine à un instant t. L'autoincrement de la base principale aura alors "déjà vécu".
Suffit-il d'un ALTER TABLE pour le faire partir avec un autre "pas" sur une nouvelle extraction?

[SQLpro]

Comme toute solution d'architecture de données, il fallait y avoir penser avant au niveau de la modélisation de la base.
Maintenant, oui, vous pouvez modifier tout cela, mais c'est loin d'être simple du fait de l'IR.

A +

[Higgins]

Comme toute solution d'architecture de données, il fallait y avoir penser avant au niveau de la modélisation de la base.

Justement, j'y pense avant
Il s'agit du portage-refonte d'une application existante et ça nous permets d'envisager toutes les demandes faites sur l'ancienne version.
La question subsidiaire que je me pose en plus est la suivante:
Dans les versions précédentes de SQL-Server, on ne pouvait pas insérer de données dans une colonne autoincrément. Si c'est toujours le cas, comment vont se passer les échanges entre les bases?
Si j'ai un id=251 sur le serveur 1 et 252 sur le serveur 2 vais-je pouvoir insérer les données d'une base dans une autre?
En fait, je pense ne pas utiliser l'autoincrement automatique et le gérer moi-même pour éviter ce type de soucis. Pour tout simplifier, je gérerai une table qui contient tous les identifiants de toutes les tables et chaque table aurait une Foreign key qui pointerait sur celle-là. Chaque ID serait alors unique dans la base.

[SQLpro]

Dans les versions précédentes de SQL-Server, on ne pouvait pas insérer de données dans une colonne autoincrément. Si c'est toujours le cas, comment vont se passer les échanges entre les bases?
Si j'ai un id=251 sur le serveur 1 et 252 sur le serveur 2 vais-je pouvoir insérer les données d'une base dans une autre?

Même si c'est peu connu, c'est depuis au moins la version 7 qu'on peut le faire... Est-te vous si dynosaureque ???
Lisez ce que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p6...ec-sql-server/

En fait, je pense ne pas utiliser l'autoincrement automatique et le gérer moi-même pour éviter ce type de soucis. Pour tout simplifier, je gérerai une table qui contient tous les identifiants de toutes les tables et chaque table aurait une Foreign key qui pointerait sur celle-là. Chaque ID serait alors unique dans la base.

Oulala !! Pensez aux problème de performance et notamment au parallélisme d'exécution... Si vous voulez pourrir les performances de votre base et générer un max de verrous, et des dead lock, c'est dans cette voie qu'il faut aller !!!

Lisez ce que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/clefs/

A +

[Higgins]

Même si c'est peu connu, c'est depuis au moins la version 7 qu'on peut le faire... Est-te vous si dynosaureque ???

C'était avec la version 2005, mais il est vrai qu'il s'agissait d'une "première approche" où je me contentais de remonter des tables provenant d'une base Sybase et je n'avais pas utilisé SET IDENTITY_INSERT #MaTable { ON | OFF }

Oulala !! Pensez aux problème de performance et notamment au parallélisme d'exécution... Si vous voulez pourrir les performances de votre base et générer un max de verrous, et des dead lock, c'est dans cette voie qu'il faut aller !!!

Je pensais n'utiliser cette table que comme "base d'information" et pas forcément l'inclure dans des requêtes.Ce serait une sorte de table des clés avec le nom de la table concernée. La foreign key entre la table cible et la table des clés aurait comme seule fonction de garantir que la clé ne peut pas être supprimée et que l'importation de données dans une table est conditionnée par la présence d'un identifiant unique dans la table des clés. Le risque de de verrous, et de dead-lock est-il aussi important dans ce cas?

[SQLpro]

Il est moindre, mais il faut quand même pratiquer le niveau d'isolation SERIALIZABLE et commencer par l'UPDATE.
Cependant, ce ne sera pas aussi rapide que le IDENTITY, ce qui conduira certainement à un point de contention dans les chargements massif, à moins de préréverser une plage de clef via la procédure de calcule de clef et l'utilisation combinée avec un ROW_NUMBER par exemple.

A +

[Higgins]

Merci pour toutes vos réponses. Il me reste deux dernières questions sur IDENTITY:
Puis-je laisser l'option SET IDENTITY_INSERT #MaTable ON à demeure ou dois-je l'activer/désactiver pour chaque opération d'insertion?
Lorsque j'insère des données dans une colonne IDENTITY, l'autoincrement repart-il bien de "là où on avait laissé"?

[zinzineti]

Merci pour votre réponse.
J'ai peur d'avoir un problème de mise "en pratique". Chaque base de données est une extraction de la base d'origine à un instant t. L'autoincrement de la base principale aura alors "déjà vécu".
Suffit-il d'un ALTER TABLE pour le faire partir avec un autre "pas" sur une nouvelle extraction?

1 ) Attention, il est impossible (en tout jusqu'à ce jour) de faire
un "ALTER TABLE" sur une table avec colonne IDENTITY. ça il faut le savoir. Bien sûr il existe une méthode de contournement pour modifier une table avec IDENTITY. mais ça c'est une autre histoire...

2 ) La proposition de SQLPRO

Sur chaque serveur/utilisateur, mettez un autoincrément avec un pas et une graine décalée.

est excellente.
Si tu n'as que 2 BASES, tu peux tout simplement appliquer des valeurs paires sur le 1er et des valeurs impaires sur le 2ème.
c-a-d :

• sur la BASE1 appliquée IDENTITY (2,2) pour les colonnes IDENTITY des tables
• sur la BASE2 appliquée IDENTITY (3,2) pour les colonnes IDENTITY des tables

A+

[SQLpro]

1 ) Attention, il est impossible (en tout jusqu'à ce jour) de faire
un "ALTER TABLE" sur une table avec colonne IDENTITY. ça il faut le savoir. Bien sûr il existe une méthode de contournement pour modifier une table avec IDENTITY. mais ça c'est une autre histoire...

Petite précision : il est possible de faire un ALTER TABLE, mais pas un ALTER COLUMN sur le colonne ayant la propriété IDENTITY.

Puis-je laisser l'option SET IDENTITY_INSERT #MaTable ON à demeure ou dois-je l'activer/désactiver pour chaque opération d'insertion?

Non (1), oui (2), car vous ne pouvez avoir qu'un seul IDENTITY_INSERT à ON en même temps dans la même session.

Lorsque j'insère des données dans une colonne IDENTITY, l'autoincrement repart-il bien de "là où on avait laissé"?

A la valeur la plus haute si le pas est positif, ou la plus basse si le pas est négatif.

A +

[Higgins]

Si tu n'as que 2 BASES, tu peux tout simplement appliquer des valeurs paires sur le 1er et des valeurs impaires sur le 2ème.
c-a-d :

• sur la BASE1 appliquée IDENTITY (2,2) pour les colonnes IDENTITY des tables
• sur la BASE2 appliquée IDENTITY (3,2) pour les colonnes IDENTITY des tables

A+

Le problème est que je ne connais pas le nombre de bases. Chaque fois que j'ai un nouveau client, je lui fournis une extraction de la base pré-remplie avec des données. Je voudrais lors d l'extraction de cette base imposer un nouveau pas, pour que les données de ce client ne télescopent ni les miennes, ni celles des clients existants.
Supposons que j'ai un pas de 250 comme dans l'exemple de SQLpro, ma base démarre à 1 et celle du client à 2.
Mes données seront les suivantes:

• ID
• -----
• 1
• 251
• 501

J'envoie cette base à mon client et je voudrais que ses propres données démarrent à 2 avec un pas de 250 également pour obtenir ça:

• ID
• -----
• 1
• 2
• 251
• 252
• 501
• 502

[zinzineti]

Je suis d'accord
Précision : le 250 dont il est question correspond au nombre maximal de client (de base de données) que tu peux avoir !!!
A+

[Higgins]

Je suis d'accord
Précision : le 250 dont il est question correspond au nombre maximal de client (de base de données) que tu peux avoir !!!
A+

C'est exactement ça. Dans la pratique se sera sûrement plus mais c'était pour l'exemple.