Discussion :

[Patrice Henrio]

Dans une table j'ai un champ ORDRE. Ce champ doit être UNIQUE. Il reflète un ordre entre deux enregistrements. Si je veux rentrer un nouvel enregistrement dont l'ordre est compris entre l'ordre de l'enregistrement a et l'ordre de l'enregistrement b comment faire.
Si ORDRE est un entier il faudra modifier tous les enregistrements x vérifiant ORDRE(x) est supérieur ou égal à ORDRE(y).
Par contre si ORDRE est un double il suffira de lui donner la valeur (ORDRE(x)+ORDRE(y)/2, encore que le nombre d'insertions possible reste quand même limitée par la précision des doubles.
Quel est cependant la meilleure solution (même si sur le papier la deuxième solution semble préférable) ?

[KookieMonster]

Souhaitez vous faire par la suite des opérations sur ce champ "ordre" ? Selon le cas, vous pouvez décider de faire une auto-jointure sur la table, un peu comme pour une table "personne" contenant le champ "parent" (unique j'entends bien dans votre cas). Quand vous insérez un nouvel enregistrement, vous n'avez qu'un seul autre enregistrement à modifier. Pas de limite liée au format comme avec DOUBLE, pas de modification de l'ensemble des lignes qui suivent, mais le parcours de cet arbre sera moins évident...

[Patrice Henrio]

Souhaitez vous faire par la suite des opérations sur ce champ "ordre" ? Selon le cas, vous pouvez décider de faire une auto-jointure sur la table, un peu comme pour une table "personne" contenant le champ "parent" (unique j'entends bien dans votre cas). Quand vous insérez un nouvel enregistrement, vous n'avez qu'un seul autre enregistrement à modifier. Pas de limite liée au format comme avec DOUBLE, pas de modification de l'ensemble des lignes qui suivent, mais le parcours de cet arbre sera moins évident...

Merci de la réponse. Effectivement j'aurai pu penser à une structure en arbre.
Cependant j'ai réfléchi depuis à ce problème et je me suis aperçu que ce cas arrive très peu souvent. Que les modifications de la base sont rares et donc même si l'opération de remaniement des champs ORDRE sont importants en terme de temps cela n'est pas grave.
Donc finalement entier et remaniement.

[Waldar]

Au lieu de mettre 1, 2, 3 vous pouvez mettre 10, 20, 30.
Comme ça vous conservez vos entiers et vous laissez un peu de marge.
Si elle ne s'avère pas suffisante dans le futur il vous reste la possibilité de tout multiplier par 10.

[Patrice Henrio]

Au lieu de mettre 1, 2, 3 vous pouvez mettre 10, 20, 30.
Comme ça vous conservez vos entiers et vous laissez un peu de marge.
Si elle ne s'avère pas suffisante dans le futur il vous reste la possibilité de tout multiplier par 10.

Effectivement c'est une bonne idée comme cela la renumérotation éventuelle sera rarissime.
Merci.

[asmduty]

Bonjour,

ne serait-il pas interessant de remplacer ordre par "suivant" (seul le dernier enregistrement aura ce champ à null)
Si on insère un nouvel enregistrement, il suffira d'indiquer dans celui-ci l'ID de l'enregistrement qui le suit (qui était dans suivant pour l'enregistrement qui précède désormais notre nouvel enregistrement) et de mettre à jour l'enregistrement qui le précède avec l'ID de notre nouvel enregistrement.

Celà dit si on veut ensuite faire des calculs comme compter combien d'enregistrements il y a avant, c'est beaucoup moins pratique.
Tout depend de l'utilité qu'on en a.

On peut aussi garder le champs ordre et faire seulement un update "Ordre = Ordre +1" pour tous les champs qui devront désormais se situer derrière.

[Patrice Henrio]

Bonjour,

ne serait-il pas interessant de remplacer ordre par "suivant" (seul le dernier enregistrement aura ce champ à null)
Si on insère un nouvel enregistrement, il suffira d'indiquer dans celui-ci l'ID de l'enregistrement qui le suit (qui était dans suivant pour l'enregistrement qui précède désormais notre nouvel enregistrement) et de mettre à jour l'enregistrement qui le précède avec l'ID de notre nouvel enregistrement.

Effectivement utiliser une file chaînée serait une solution

Celà dit si on veut ensuite faire des calculs comme compter combien d'enregistrements il y a avant, c'est beaucoup moins pratique.
Tout depend de l'utilité qu'on en a.

On peut aussi garder le champs ordre et faire seulement un update "Ordre = Ordre +1" pour tous les champs qui devront désormais se situer derrière.

Dans le cas qui m'intéresse : je dois récupérer un certain nombre d'enregistrement et les traiter un par un par dans l'ordre du champ ORDRE. Donc je crains que cette solution ne convienne pas.
Peux-tu m'en dire plus sur la requête avec ORDRE=ORDRE+1
Supposons que je veuille insérer un nouvel enregistrement dont l'ordre vaut 100.
Avant l'insertion je commence d'abord par sélectionner tous les enregistrements tel que ORDRE>= 100.
J'applique à chacun de ces enregistrements ORDRE = ORDRE+1 (en commençant par le dernier pour ne pas avoir de problème avec la contrainte d'unicité sur ORDRE). Ensuite j''insère le nouvel enregistrement.
Peux-tu me détailler les lignes SQL correspondantes ?

[asmduty]

Je pense qu'un simple "UPDATE matable SET ordre = ordre+1 WHERE ordre >= 100" peut suffir.
Comme on est sur une clé à vérifier si ça passe ou non par des tests, c'est pas forcément gagné.
Et ensuite on peut faire notre insertion comme tu l'as bien dit.

[Patrice Henrio]

Je pense qu'un simple "UPDATE matable SET ordre = ordre+1 WHERE ordre >= 100" peut suffir.
Comme on est sur une clé à vérifier si ça passe ou non par des tests, c'est pas forcément gagné.
Et ensuite on peut faire notre insertion comme tu l'as bien dit.

Merci. je vais essayer cela.