Dans un site, j'ai une page avec un affichage de spectacles, tout ça est administrable (ajout/suppression/modification/masquage/demasquage), mais il manque encore une chose importante que je m'apprete à rajouter: l'ordre d'affichage.
Pour le moment c'est trier par date, mais la personne qui va administrer le site veut absolument pouvoir changer l'ordre d'affichage.
 
Je vais rajouter un champ "ordre" (type int) dans la table, et je pense à cette solution:
Quand on fait descendre/remonter un spectacle, on cherche le spectacle avec la valeur "ordre" immédiatement supérieure/inferieure, et on inverse la valeur ordre du spectacle actuel avec celle-ci (et idem pour le spectacle qui prends la place, enfin vous comprenez...), ce qui a l'avantage de ne pas poser de problème en cas de suppression de spectacle (qui laisserait un trou dans la la liste des ordre)
 
Pour la requete, je verrai quelque chose comme ça, pour faire descendre un spectacle:
SELECT id FROM spectacles WHERE ordre > $ordreDeMonSpectacle ORDER BY ordre LIMIT 1
 
bon? pas bon? qu'est-ce qu'il y'a de mieux ?  
 
Merci

ordonnes les de 1 à x mettons.
en cas de suppression du spectacle y, tu supprimes ta ligne sql & tu fais une boucle while qui transforme toute les valeurs supérieur a y en y-1 (ce qui fera remonter d'une ligne tous les spectacles).
 
et ensuite, pour les montée/descente, fais une interface dans l'administration avec pour chaque ligne une fleche vers le haut (pour faire monter la ligne) et une fleche vers le bas (pour faire descendre la ligne). en cas de clic sur la fleche du haut de la ligne y, tu attribue une valeur temporaire a ligne du dessus (la ligne y-1), puis tu attribues a y la valeur de y-1 (ta ligne remonte) et enfin tu attribues a la ligne qui etait au dessus (y-1 au debut) la position y. et hop les deux lignes ont permutés. en repetant l'opération l'utilisateur qui administre pourra faire bouger ses spectacles où il veut!

Si tes spectacles ont déjà un id (genre autoincrement), ça ne sert à rien de rajouter une colonne pour l'ordre, tu fais juste un ORDER BY id DESC
et dans l'admin, pour remonter un spectacle en haut, tu fais un
INSERT INTO table_spectacle SELECT * FROM table_spectacle WHERE id='l'idquetuveuxremonter'
DELETE l'idquetuveuxremonter
OPTIMIZE pour boucher le trou
 
et hop là
 
prévoit un int(10) pour l'id et t'es tranquille quelques années.

 
J'ai pensé à ça, mais le traitement me parait un peu lourd (si au bout de 3 ans y'a 500 spectacles, ca commence à faire pas mal )

 
Pas mal, mais ca fait remonter un spectacle tout en haut, pas juste d'une case en haut, ce qui n'est pas top
 
(ps: je ne peux pas changer l'id d'un spectacle, j'ai d'autres pages avec des choses qui pointent vers des spectacles, ca ferait des changement à faire un peu partout dans des tables)
 
Merci quand meme, la solution pourrait me resservir pour d'autres choses

remarque, tu dois pouvoir faire une requete mysql qui ferait çà toute seule :
UPDATE table SET ordre = ordre - 1 WHERE ordre > y
 
du coup çà ne te fait qu'une requete sql, c'est pas lourd du tout

Ah oui, possible, j'essaye ça de suite sur une table bidon
 
edit: ca fonctionne, donc la solution deviens très interressante, ca me fera une table sans trou, et une facilité à gérer l'ordre (un simple +1/-1 sur les deux lignes concernées lors d'un changement, et l'update bouche-trou uniquement lors d'une suppression)
 
impec merci

Est-ce vraiment un problème ?  
 
Je verrais plutôt une table à part, indépendante de la table principale  
Et en tout cas, ne pas toucher à l'id de la table spectacle. Le principe d'un id, c'est d'identifier, donc ca devrait être une valeur fixe, qui n'est jamais modifiée.

Je suis plutôt d'accord    
 
J'aurais aussi pensé à l'idée de départ de l'auteur, c'est d'ailleurs ce que j'ai toujours fait quand j'en ai eu besoin Maintenant en effet sur des grosses bases (ce qui n'était pas mon cas et qui le sera peut être pas pour aspegic) ça doit faire mouliner pas mal de données pour tout updater    
 
 
Aspegic, pour être bien sur de comprendre, il veut pouvoir ordonner lui même c'est ça

 
Tout à fait d'accord pour l'id, ca identifie de manière unique un élément, donc ca ne change pas.
 
Pour une autre table, je vois pas ce que j'y mettrai, à part l'id_spectacle et l'ordre, ce que j'ai déjà dans ma table actuelle
 
En effet pour le trou c'est pas vraiment un problème, mais c'est un peu plus crade je trouve

 
Oui voilà je veux ordonner de manière manuelle, pas selon un champ déjà "utile" de la table (comme nom, date, etc...)
 
C'est vrai que pour une grosse base (dizaines ou centaines de milliers d'enregistrements), le traitement lors d'une suppression peut devenir embétant, mais là ce n'est pas mon cas (même dans 10 ans y'aura pas plus de 5000 enregistrements)
 
Cela dit pour info, quelle solution utiliseriez-vous pour une grosse base et des suppressions relativement fréquentes ?  

Pourquoi pas ?
 
Ca peut être bien de séparer ces 2 infos. En fait, je pense que ca dépend de la fréquence d'actualisation du tri. Si c'est fait rarement, c'est vrai que c'est pas fondamental d'isoler ces infos

Une autre table faite pour gérer ça sans inpacter les données à proprement parler De façon à pas mélanger données et affichage, genre je fais une recherche par nom ou date, j'ai pas besoin d'avoir de notion d'ordre choisi
 
Maintenant il est parfois préférable d'avoir une table énorme que faire des jointures sur des tables énormes   Celà dit ça n'empêche de garder le concept de tables différenciées mais regroupées ailleurs  

Dans ce cas ca serait une dénormalisation pour gagner en performances ? (je comprends, vu que la table est lockée pendant l'update complet après la suppression, c'est top )
 
Parce que bon là on aurait ces 2 tables là:
spectacles (id,nom,date,actif)
ordre (id_spectacle,ordre)
 
Quand on affiche les spectacles, on les prends dans la table "ordre", mais il faut une jointure avec la table "spectacles" pour récupérer les infos, je ne sais pas quel est l'impact d'une jointure comme ça sur les performances

Pas forcément pour les update ou delete, c'est le principe du datawarehouse: les formes normales et l'entité-relation c'est bien comme théorie, ça permet de faire propre mais nier la lourdeur quand y'en a besoin c'est stupide, mais on dérive là

Si y'a pas trop de lignes ça bouffera plus mais pas grand chose, maintenant si tu fais une recherche tu te sers que de spectacle
 
 
M'enfin, vu ton cdc (ie pas beaucoup de tupples) te prends pas la tête sauf si t'as d'autres choses à faire dans ce gout là Dans la table spectacle et on en parle plus Si tu veux faire propre, ordre et jointure tu perdras pas grand chose avec les index qui vont bien surtout sur une petite table