Je voudrais créer une table avec un champ qui me sert à définir l'ordre de
mes enregistrements.
Pour ça j'ai deux méthodes.
- Utiliser un champ qui définie l'ordre (1 à 10000)
- Utiliser les listes chainées (le champ définie l'Id de l'enregistrement
suivant)
La première méthode semble plus gourmande car dans le cas ou je positionne
le 10000ème enregistrement en premier il faut modifier 9999 enregistrements.
Donc une requête du genre :
UPDATE maTable SET Ordre=Ordre+1 where Ordre>=nouvellePosition
Dans la deuxième méthode il suffit de modifier qu'un enregistrement (voir
aucun si on place le dernier enregistrement en premier) mais dans ce cas là
il faut tout de même faire un SELECT pour obtenir l'ID de l'enregistrement
lié pour ensuite faire UPDATE sur celui-ci.
Donc d'après vous quel est la méthode la plus efficace ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jérôme Quintard
> > La première méthode semble plus gourmande car dans le cas ou je
positionne
> le 10000ème enregistrement en premier il faut modifier 9999
enregistrements.
> Donc une requête du genre :²
NON ! Si les lignes sont numérotées de 1 à 10000, alors pour mettre le premier en dernier il suffit de lui donner la valeur MAX+1 soit 10001 ! Donc un update d'une seule ligne
Heuu ?? J'ai marqué le 10000ème en premier :o) Toi tu me parle de l'inverse :o) Mais dans ton cas c'effectivement ça :o)
> Dans la deuxième méthode il suffit de modifier qu'un enregistrement
(voir
> aucun si on place le dernier enregistrement en premier) mais dans ce cas
là
> il faut tout de même faire un SELECT pour obtenir l'ID de
Il a donc fallut que je modife tous les ordre >1 pour ORDRE+1. Pour mettre le premier en dernier soit on augment l'ordre max de 1 (comme ton exemple) soit en décale encore une fois...
Dans la seconde méthode on indique le prochain ID d'où :
On utilise le 0 pour indiqué que l'enregistrement n'est pas 'relié' (c'est donc le dernier dans l'ordre..). Si on ajoute le quatrième enregistrement on obtient :
PDG est bien le premier dans l'ordre et je n'ai fais aucun changement sur les autres enregistrements (parce que c'est le premier). Si PDG avait du être le second j'aurai eu à modifier Directeur pour le relier à PDG et indiqué à mon enregistrement qu'il était relié à Technicien. Soit ceci :
Bon la logique me semble clair mais maintenant je vois pas trop en SQL comment récupérer avec ça l'ordre de ma liste... faudrait que j'ai :
1->4--4->2--2->3--3->0
Souvent la problématique des tris complex est résolu par des tables externes que l'on lie à la table que l'on veut trier.
Sauf que je peux pas. Je m'explique. J'ai conçu un générateur de back-office pour le web qui fonctionne avec la majorité des bases de données. Pour qu'il soit simple d'utilisation pour les développeur, il me faut simplifier au maximum la construction des tables. Si je commence à dire aux gens : pour faire un tri, il faut ajouter une table avec x champs, faire une relation... (sans parler que les relations n'existe pas partout :o). Enfin voilà le dilem... c'est pour ça que j'aimerai resté sur un champ de typer Integer (et ses dérivés supérieurs) pour la gestion de l'ordre....
A++
> > La première méthode semble plus gourmande car dans le cas ou je
positionne
> le 10000ème enregistrement en premier il faut modifier 9999
enregistrements.
> Donc une requête du genre :²
NON ! Si les lignes sont numérotées de 1 à 10000, alors pour mettre le
premier en dernier il suffit de lui donner la valeur MAX+1 soit 10001 !
Donc un update d'une seule ligne
Heuu ?? J'ai marqué le 10000ème en premier :o) Toi tu me parle de l'inverse
:o) Mais dans ton cas c'effectivement ça :o)
> Dans la deuxième méthode il suffit de modifier qu'un enregistrement
(voir
> aucun si on place le dernier enregistrement en premier) mais dans ce cas
là
> il faut tout de même faire un SELECT pour obtenir l'ID de
Il a donc fallut que je modife tous les ordre >1 pour ORDRE+1. Pour mettre
le premier en dernier soit on augment l'ordre max de 1 (comme ton exemple)
soit en décale encore une fois...
Dans la seconde méthode on indique le prochain ID d'où :
On utilise le 0 pour indiqué que l'enregistrement n'est pas 'relié' (c'est
donc le dernier dans l'ordre..).
Si on ajoute le quatrième enregistrement on obtient :
PDG est bien le premier dans l'ordre et je n'ai fais aucun changement sur
les autres enregistrements (parce que c'est le premier). Si PDG avait du
être le second j'aurai eu à modifier Directeur pour le relier à PDG et
indiqué à mon enregistrement qu'il était relié à Technicien. Soit ceci :
Bon la logique me semble clair mais maintenant je vois pas trop en SQL
comment récupérer avec ça l'ordre de ma liste... faudrait que j'ai :
1->4--4->2--2->3--3->0
Souvent la problématique des tris complex est résolu par des tables
externes que l'on lie à la table que l'on veut trier.
Sauf que je peux pas. Je m'explique. J'ai conçu un générateur de back-office
pour le web qui fonctionne avec la majorité des bases de données. Pour qu'il
soit simple d'utilisation pour les développeur, il me faut simplifier au
maximum la construction des tables. Si je commence à dire aux gens : pour
faire un tri, il faut ajouter une table avec x champs, faire une relation...
(sans parler que les relations n'existe pas partout :o). Enfin voilà le
dilem... c'est pour ça que j'aimerai resté sur un champ de typer Integer (et
ses dérivés supérieurs) pour la gestion de l'ordre....
> > La première méthode semble plus gourmande car dans le cas ou je
positionne
> le 10000ème enregistrement en premier il faut modifier 9999
enregistrements.
> Donc une requête du genre :²
NON ! Si les lignes sont numérotées de 1 à 10000, alors pour mettre le premier en dernier il suffit de lui donner la valeur MAX+1 soit 10001 ! Donc un update d'une seule ligne
Heuu ?? J'ai marqué le 10000ème en premier :o) Toi tu me parle de l'inverse :o) Mais dans ton cas c'effectivement ça :o)
> Dans la deuxième méthode il suffit de modifier qu'un enregistrement
(voir
> aucun si on place le dernier enregistrement en premier) mais dans ce cas
là
> il faut tout de même faire un SELECT pour obtenir l'ID de
Il a donc fallut que je modife tous les ordre >1 pour ORDRE+1. Pour mettre le premier en dernier soit on augment l'ordre max de 1 (comme ton exemple) soit en décale encore une fois...
Dans la seconde méthode on indique le prochain ID d'où :
On utilise le 0 pour indiqué que l'enregistrement n'est pas 'relié' (c'est donc le dernier dans l'ordre..). Si on ajoute le quatrième enregistrement on obtient :
PDG est bien le premier dans l'ordre et je n'ai fais aucun changement sur les autres enregistrements (parce que c'est le premier). Si PDG avait du être le second j'aurai eu à modifier Directeur pour le relier à PDG et indiqué à mon enregistrement qu'il était relié à Technicien. Soit ceci :
Bon la logique me semble clair mais maintenant je vois pas trop en SQL comment récupérer avec ça l'ordre de ma liste... faudrait que j'ai :
1->4--4->2--2->3--3->0
Souvent la problématique des tris complex est résolu par des tables externes que l'on lie à la table que l'on veut trier.
Sauf que je peux pas. Je m'explique. J'ai conçu un générateur de back-office pour le web qui fonctionne avec la majorité des bases de données. Pour qu'il soit simple d'utilisation pour les développeur, il me faut simplifier au maximum la construction des tables. Si je commence à dire aux gens : pour faire un tri, il faut ajouter une table avec x champs, faire une relation... (sans parler que les relations n'existe pas partout :o). Enfin voilà le dilem... c'est pour ça que j'aimerai resté sur un champ de typer Integer (et ses dérivés supérieurs) pour la gestion de l'ordre....
