[MySQL] Orderen by 'status'

[Saven]

Tweakers

Ik was weer even het een en ander aan het uitproberen voor een systeempje van mij; een forum om preciezer te zijn.
Ik heb op dit moment een tabel 'topic' welke een veld 'status' bevat.

De volgende mogelijkheden voor dit veld zijn:

PHP:

//-----------------------------------------
// Define topic statusses
//-----------------------------------------
define('TOPIC_OPEN',   1);
define('TOPIC_NORMAL', 1);

define('TOPIC_LOCKED', 2);
define('TOPIC_CLOSED', 2);

define('TOPIC_STICKY', 3);
define('TOPIC_PINNED', 3);

define('TOPIC_LOCKED_STICKY', 4);
define('TOPIC_CLOSED_STICKY', 4);
define('TOPIC_STICKY_LOCKED', 4);
define('TOPIC_STICKY_CLOSED', 4);

De dubbele defines is puur uit gemakswerk mocht ik een keer niet meer zeker weten wat het ook al precies was
Maargoed, daar gaat het even niet om

Ik wil dus via een query alle topics uit een categorie listen (althans, een stuk of 40, de rest komt op de volgende pagina's).
Het probleem is alleen dat ik op de eerste pagina alle sticky topics, dus topics met status 3 of 4 bovenaan komen.

Als ik dit via een aparte query zou opvragen wordt het nogal lelijk om helemaal uit te gaan rekenen hoeveel normale topics maar op pagina 1 moet. Want stel ik list 50 topic per pagina, en 20 daarvan zijn sticky, dan mag ik maar 30 normale topics op pagina 1 hebben, en 50 op pagina twee, 50 op pagina 3 etc..

Dus ik wilde dit graag in één query verwezelijken. Alleen mijn manier met:

SQL:

ORDER BY status

werkt logischerwijs niet, want ik wil ook nog eens de rest van de topics gewoon op tijd van laatste reply sorteren.

Is er misschien iemand die mij hier mee wat kan helpen? Thanks

[Verwijderd]

Waarom niet gewoon aparte velden voor "closed" en "sticky"?

[NMe]

Of desnoods bitmasks. Hoewel dit ook wel op te lossen is (hint: CASE...WHEN) moet je dat niet willen, dit is gewoon een kromme opzet.

[ Voor 73% gewijzigd door NMe op 02-01-2010 01:57 ]

[Saven]

NMe schreef op zaterdag 02 januari 2010 @ 01:56:
Of desnoods bitmasks.

Snel even wat gegoogled, maar daar word ik niet echt wijzer van

De aparte velden voor closed en sticky is ooit aan gedacht, maar het leek mij -toen- makkelijker

[Herko_ter_Horst]

Met Cheatah en bedoel je niet gewoon "ORDER BY status, lastmodified"?

[Saven]

Nope want dan ordert ie ook alle gesloten topics bij elkaar. Dat is niet de bedoeling

[Herko_ter_Horst]

Dan zul je even nader moeten uitleggen wat wel de bedoeling is.

[GlowMouse]

Afstappen van je 50 posts/pagina, of toch twee queries uitvoeren en rekenen. Zo erg is dat helemaal niet, twee queries hiervoor.

[Verwijderd]

Ik zat eerst aan order by field te denken maar toen las ik het nog een keer
Voor zover ik het begrijp wil je sorteren op status waarbij 3 en 4 hetzelfde "gewicht" hebben en dus bovenaan komen en daarna moet al het andere volgen?

[NMe]

GlowMouse schreef op zaterdag 02 januari 2010 @ 02:04:
Afstappen van je 50 posts/pagina, of toch twee queries uitvoeren en rekenen. Zo erg is dat helemaal niet, twee queries hiervoor.

Maar waarom? Waarom zou je in een fatsoenlijke opzet niet kunnen orderen op status, datum DESC? Deze opzet is gewoon niet goed. Dus maak er ofwel twee statusvelden van, ofwel een bitmask, al lost dat laatste je sorteerprobleem niet op.

Nogmaals, mijn eerder genoemde workaround kan vast ook, maar je doet er gewoon beter aan om dit fatsoenlijk op te zetten. Wat nou als je later nog een status toe wil voegen? "Announcements" ofzo? Dan kun je dus die status toevoegen plus alle mogelijke combinaties en dan kun je daarna ook nog eens alle code gaan doorzoeken om de sortering weer goed te krijgen voor gesloten announcements e.d.

Oh, en nog een kleine opmerking: WTF @ 4 verschillende namen voor dezelfde constante. Als je ze nu ook nog eens allevier gebruikt in je code wordt dat vast heel erg lekker onderhoudbaar....not.

[ Voor 9% gewijzigd door NMe op 02-01-2010 02:10 ]

[Saven]

Verwijderd schreef op zaterdag 02 januari 2010 @ 02:05:
Ik zat eerst aan order by field te denken maar toen las ik het nog een keer
Voor zover ik het begrijp wil je sorteren op status waarbij 3 en 4 hetzelfde "gewicht" hebben en dus bovenaan komen en daarna moet al het andere volgen?

klopt

NMe schreef op zaterdag 02 januari 2010 @ 02:09:
[...]

Maar waarom? Waarom zou je in een fatsoenlijke opzet niet kunnen orderen op status, datum DESC? Deze opzet is gewoon niet goed. Dus maak er ofwel twee statusvelden van, ofwel een bitmask, al lost dat laatste je sorteerprobleem niet op.

Nogmaals, mijn eerder genoemde workaround kan vast ook, maar je doet er gewoon beter aan om dit fatsoenlijk op te zetten. Wat nou als je later nog een status toe wil voegen? "Announcements" ofzo? Dan kun je dus die status toevoegen plus alle mogelijke combinaties en dan kun je daarna ook nog eens alle code gaan doorzoeken om de sortering weer goed te krijgen voor gesloten announcements e.d.

Oh, en nog een kleine opmerking: WTF @ 4 verschillende namen voor dezelfde constante. Als je ze nu ook nog eens allevier gebruikt in je code wordt dat vast heel erg lekker onderhoudbaar....not.

Ik gooi de boel wel even om

En die 4 defines, ik weet het

[ Voor 60% gewijzigd door Saven op 02-01-2010 02:12 ]

[GlowMouse]

NMe schreef op zaterdag 02 januari 2010 @ 02:09:
[...]

Maar waarom? Waarom zou je in een fatsoenlijke opzet niet kunnen orderen op status, datum DESC?

Omdat je niet alleen met sticky en open zit, maar ook nog met closed. Closed moet niet pas op de laatste pagina komen.