[MySQL] ASC en DESC sorteren door elkaar

[Vinze]

Ik probeer een query te bouwen waarmee ik de resultaten met een datum in de toekomst en vandaag ascending wil sorteren en de datum in het verleden descending wil sorteren.

Het resultaat zou dan ongeveer zoiets moeten zijn:

code:

2018-09-27
2018-09-28
2018-09-30
2018-10-05
---
2018-09-20
2018-09-14
2018-07-25
2018-07-16

Nu kom ik met de volgende query het verst, maar nu worden de toekomstige datums én de datums in het verleden ascending gesorteerd. De datums in het verleden moeten dus nog descending gesorteerd worden.

SQL:

SELECT * FROM tabel ORDER BY CASE WHEN DATE(datum) < DATE(CURDATE()) THEN 0 ELSE 1 END DESC, datum ASC

Waarschijnlijk is het iets heel simpels, maar in mijn beleving heb ik inmiddels alle mogelijke combinaties al geprobeerd. Iemand enig idee of en hoe ik dit voor elkaar kan krijgen?

[NMe]

MySQL:

SELECT * FROM tabel
ORDER BY CASE WHEN DATE(datum) < DATE(CURDATE()) THEN 0 ELSE 1 END DESC,
    ABS(DATEDIFF(datum, CURDATE())) ASC

[ Voor 3% gewijzigd door NMe op 27-09-2018 14:43 ]

[vdws]

Unions ;-)

SQL:

select datum
from
  (select to_char(datum) datum
  from tabel
  where datum >= curdate()
  order by datum asc
  ) t1
union
  select '-----' 
union
  select datum
  from
    (select to_char(datum) datum
    from tabel
    where datum < curdate()
    order by datum desc
    ) t2

[ Voor 6% gewijzigd door vdws op 27-09-2018 15:00 ]

[emnich]

NMe schreef op donderdag 27 september 2018 @ 14:42:

MySQL:

SELECT * FROM tabel
ORDER BY CASE WHEN DATE(datum) < DATE(CURDATE()) THEN 0 ELSE 1 END DESC,
    ABS(DATEDIFF(datum, CURDATE())) ASC

Dat wordt performance-technisch natuurlijk wel een drama...

[NMe]

emnich schreef op donderdag 27 september 2018 @ 15:04:
[...]

Dat wordt performance-technisch natuurlijk wel een drama...

Uiteraard, maar ik zie als het in MySQL moet geen heel veel betere oplossing; ook de union hierboven zal niet heel erg snel zijn. Gevalletje meten is weten trouwens, misschien valt het uiteindelijk in deze dataset wel mee. Als het inderdaad heel traag is zou ik 't gewoon in PHP (of welke taal je ook gebruikt voor de applicatie waar dit in wordt gebruikt) oplossen.

[ Voor 5% gewijzigd door NMe op 27-09-2018 15:07 ]

[Vinze]

NMe schreef op donderdag 27 september 2018 @ 14:42:

MySQL:

SELECT * FROM tabel
ORDER BY CASE WHEN DATE(datum) < DATE(CURDATE()) THEN 0 ELSE 1 END DESC,
    ABS(DATEDIFF(datum, CURDATE())) ASC

Top, thanks! Ik was er al bijna dus

emnich schreef op donderdag 27 september 2018 @ 15:04:
[...]

Dat wordt performance-technisch natuurlijk wel een drama...

Dat zal niet meteen een probleem zijn. Ik haal alleen de resultaten van de afgelopen 3 maanden op en dat zullen misschien een paar 100 records zijn.

[DaCoTa]

Ik denk dat NMe hier wel het juiste punt aanhaalt: dit klinkt als logica die meer aan de voorkant moet zitten, je wil de database helemaal niet opschepen met dit soort sorteerdingen. Gewoon sorteren in je applicatie, is hoogst waarschijnlijk eenvoudiger, leesbaarder en makkelijker onderhoudbaar.

Een van de dingen die je nu nml. niet hebt, is de plek waar de sortering omdraait, daar waar je nu een streepje hebt staan. Dat zul je dus toch sowieso al in code moeten doen, dus dan kan je net zo goed de hele sortering daar doen.

[ Voor 28% gewijzigd door DaCoTa op 02-10-2018 11:12 ]

[Gomez12]

DaCoTa schreef op dinsdag 2 oktober 2018 @ 11:11:
Ik denk dat NMe hier wel het juiste punt aanhaalt: dit klinkt als logica die meer aan de voorkant moet zitten, je wil de database helemaal niet opschepen met dit soort sorteerdingen. Gewoon sorteren in je applicatie, is hoogst waarschijnlijk eenvoudiger, leesbaarder en makkelijker onderhoudbaar.

Een van de dingen die je nu nml. niet hebt, is de plek waar de sortering omdraait, daar waar je nu een streepje hebt staan. Dat zul je dus toch sowieso al in code moeten doen, dus dan kan je net zo goed de hele sortering daar doen.

Hmmm, sorteren is nu net een van de twijfeldingetjes.

Het nadeel van sorteren in app is weer dat je alles in memory moet laden voordat je kan beginnen... Wat leuk is als je een recordset van een paar miljoen/miljard hebt. Plus dat je gigantisch moeilijk moet gaan doen met paging etc. etc.

Persoonlijk denk ik dat ik als dit een harde eis zou zijn, dat ik voor 2 query's zou gaan. De vraag is gewoon echt anders (en veelal zie ik ook dat de conditites anders zijn, bijv in het verleden mogen gesloten wel weggelaten worden, in de toekomst gesloten moet getoond worden)

[DaCoTa]

Gomez12 schreef op dinsdag 2 oktober 2018 @ 11:35:
[...]

Hmmm, sorteren is nu net een van de twijfeldingetjes.

Het nadeel van sorteren in app is weer dat je alles in memory moet laden voordat je kan beginnen... Wat leuk is als je een recordset van een paar miljoen/miljard hebt. Plus dat je gigantisch moeilijk moet gaan doen met paging etc. etc.

Persoonlijk denk ik dat ik als dit een harde eis zou zijn, dat ik voor 2 query's zou gaan. De vraag is gewoon echt anders (en veelal zie ik ook dat de conditites anders zijn, bijv in het verleden mogen gesloten wel weggelaten worden, in de toekomst gesloten moet getoond worden)

Ja uiteraard, maar in dit geval, met een dataset van een paar 100 items, is leesbaarheid imo het belangrijkste. De query zoals daarboven is gewoon niet makkelijk leesbaar aangezien het twee conflucterende sorteeracties zijn.

Twee queries maakt de oplossing waarschijnlijk nog veel eenvoudiger. Even de aanname dat er tijd genoeg is voor een tweede query en het niet in een high-performance omgeving draait.

[Gomez12]

DaCoTa schreef op dinsdag 2 oktober 2018 @ 11:41:
[...]
Ja uiteraard, maar in dit geval, met een dataset van een paar 100 items, is leesbaarheid imo het belangrijkste. De query zoals daarboven is gewoon niet makkelijk leesbaar aangezien het twee conflucterende sorteeracties zijn.

In code ga je hetzelfde probleem creeeren, dan is het daar gewoon niet makkelijk leesbaar aangezien het twee conflucterende sorteeracties zijn.

Dat maakt volgens jouw argumentatie geen barst uit.Ik zou zeggen dat ik al mijn query's in sql gesorteerd heb, dus dan dit ding ook maar met een onhandige constructie mocht het niet in 2'en kunnen. Dan houd ik tenminste aan het interne plan vast dat een query gewoon de resultaten in een datagrid geeft.

Twee queries maakt de oplossing waarschijnlijk nog veel eenvoudiger. Even de aanname dat er tijd genoeg is voor een tweede query en het niet in een high-performance omgeving draait.

In een high performance omgeving ga je juist met 2 query's werken en juist niet met vage sql-trucjes en zeker niet met grappen als sorteren in code.