[SQL] Query op product ID's maar sortering niet juist

[Urk]

Ik heb (even simpeler gemaakt) de volgende query:

SQL:

SELECT products.* WHERE product_actief = 1 AND (product_id = 7341 OR product_id = 7317 OR product_id = 7386 OR product_id = 7406 OR product_id = 7011)

Als ik deze query uitvoer wordt deze gesorteerd op product_id, dus van laag naar hoog. Ik wil echter dat hij sorteert in de volgorde van opgave van product_id.
Dus eerste record moet zijn product_id = 7341, daarna 7317, daarna 7386 etc.
Ik krijg dat niet voor elkaar, ook niet met iets van een rowid() functie oid.

Iemand enig idee hoe ik deze volgorde in de recordset terug kan krijgen?

[RobIII]

Ik wil echter dat hij sorteert in de volgorde van opgave van product_id.

Dat gaat niet. Punt.

Je kunt met een Case When ... een tweede ("virtueel") veld erbij selecteren waarbij je de order "hardcode" en daarop sorteren maar... mooi is anders.

[ Voor 43% gewijzigd door RobIII op 20-07-2020 12:59 ]

[The Eagle]

Zelf de sorteervolgorder aangeven wordt idd een dingetje, in principe gaat dat niet nee.
Op welke DB voer je dit uit trouwens, en wat is het datatype van de kolom product?

Verder benieuwd wat je probeert te bereiken hiermee. Waarom zou je zelf een sortering aan willen geven?

[coop]

Dit zou moeten werken. Moet je wel zelf de volgorde meegeven in de ORDER BY.

code:

SELECT products.* WHERE product_actief = 1 AND product_id IN (7341, 7317, 7386, 7406, 7011) ORDER BY CASE WHEN product_id = 7341 THEN 1 WHEN product_id = 7317 THEN 2 WHEN product_id = 7386 THEN 3 WHEN product_id = 7406 THEN 4 WHEN product_id = 7011 THEN 5 Else product_id END ASC

Tevens is x IN () meestal sneller dan meerdere ORs, maar dat is afhankelijk van het aantal mogelijkheden.

[scatman]

Via een omweg gaat dit wel:

code:

select 1, * from products where Id=4
Union
Select 2, * from products where id=3
Union
...
Order by 1

[Urk]

The Eagle schreef op maandag 20 juli 2020 @ 12:58:
Zelf de sorteervolgorder aangeven wordt idd een dingetje, in principe gaat dat niet nee.
Op welke DB voer je dit uit trouwens, en wat is het datatype van de kolom product?

Verder benieuwd wat je probeert te bereiken hiermee. Waarom zou je zelf een sortering aan willen geven?

Sorry, slordig dat ik dat natuurlijk niet heb vermeld. Het betreft Microsoft SQL Server 2016.
product_id = Integer

Wat ik hiermee wil bereiken: dit is een query die wordt gebruikt in een product vergelijk functie. Aangezien er na deze query en een 2e query wordt uitgevoerd om alle producteigenschappen op te halen en deze door de nodige subquery wel in deze volgorde is te doen moet de eerste query daar natuurlijk wel op aansluiten.

[Orion84]

Maar waarom moeten die twee queries de resultaten in dezelfde volgorde teruggeven? Dit klinkt eerder als iets dat je gewoon fatsoenlijk moet afhandelen in de rest van je code.

[Hydra]

Urk schreef op maandag 20 juli 2020 @ 12:45:
Ik heb (even simpeler gemaakt) de volgende query:

SQL:

SELECT products.* WHERE product_actief = 1 AND (product_id = 7341 OR product_id = 7317 OR product_id = 7386 OR product_id = 7406 OR product_id = 7011)

Je kunt ook dit doen als het goed is:

SQL:

SELECT products.* WHERE product_actief = 1 AND product_id = IN(7341,7317,7386,7406,7011)

Iets nettere query.

Als ik deze query uitvoer wordt deze gesorteerd op product_id, dus van laag naar hoog. Ik wil echter dat hij sorteert in de volgorde van opgave van product_id.

Het kan wel maar ik zou dat gewoon lekker in de code doen, het zijn maar een paar records dus moeilijk gaan lopen doen met het erin joinen van getallen om erop te sorteren.

[Hydra]

Urk schreef op maandag 20 juli 2020 @ 13:17:
Wat ik hiermee wil bereiken: dit is een query die wordt gebruikt in een product vergelijk functie. Aangezien er na deze query en een 2e query wordt uitgevoerd om alle producteigenschappen op te halen en deze door de nodige subquery wel in deze volgorde is te doen moet de eerste query daar natuurlijk wel op aansluiten.

Dat kan je dan gewoon met 1 query doen, daarna die max 5 rows in je applicatie sorteren.

[nescafe]

Met een table variable kan het wel:

SQL:

DECLARE @selection TABLE ( product_id INT, seq_no INT IDENTITY )

INSERT @selection VALUES ( 7341 ), ( 7317 ), ( 7386 ), ( 7406 ), ( 7011 )

SELECT p.*
FROM products p
  INNER JOIN @selection s ON p.product_id = s.product_id
WHERE p.product_actief = 1
ORDER BY s.seq_no

[nescafe]

coop schreef op maandag 20 juli 2020 @ 13:04:
Tevens is x IN () meestal sneller dan meerdere ORs, maar dat is afhankelijk van het aantal mogelijkheden.

Ik ben benieuwd of dat meestal sneller is. Een IN (a, b) wordt intern uitschreven als losse vergelijkingen verbonden met OR. Maak maar eens een tikfout in de kolomnaam, die zie je meerdere malen terug:

SQL:

SELECT * FROM products WHERE dummy IN ( 1, 2, 3 )

Error 207: Invalid column name 'dummy'.
Invalid column name 'dummy'.
Invalid column name 'dummy'.

[ Voor 3% gewijzigd door nescafe op 20-07-2020 13:51 ]

[Urk]

Hydra schreef op maandag 20 juli 2020 @ 13:36:
[...]


Je kunt ook dit doen als het goed is:

SQL:

SELECT products.* WHERE product_actief = 1 AND product_id = IN(7341,7317,7386,7406,7011)

Iets nettere query.


[...]

Het kan wel maar ik zou dat gewoon lekker in de code doen, het zijn maar een paar records dus moeilijk gaan lopen doen met het erin joinen van getallen om erop te sorteren.

Dank je, maar deze query accepteert SQL niet, krijg de volgende error:
Incorrect syntax near the keyword 'IN'.

[Urk]

Orion84 schreef op maandag 20 juli 2020 @ 13:22:
Maar waarom moeten die twee queries de resultaten in dezelfde volgorde teruggeven? Dit klinkt eerder als iets dat je gewoon fatsoenlijk moet afhandelen in de rest van je code.

Ja, daar ben ik het opzich wel mee eens, ik had al een idee de andere query gewoon van laag naar hoog uit te voeren en deze dan ook. Echter als ik het in SQL op een makkelijke manier kan doen heeft dat de voorkeur

[Cyphax]

Urk schreef op maandag 20 juli 2020 @ 13:55:
[...]

Dank je, maar deze query accepteert SQL niet, krijg de volgende error:
Incorrect syntax near the keyword 'IN'.

Dan moet je even die = weghalen, die hoort daar niet thuis. Maar dan nog krijg je volgens mij niet je gewenste volgorde.
De vraag is: wat is de logica achter jouw gewenste volgorde en kan je die in SQL uitdrukken (het is niet willekeurig) mbv andere kolommen, of eventueel op een andere manier? Anders zul je ze los moeten ophalen.

[ Voor 4% gewijzigd door Cyphax op 20-07-2020 13:58 ]

[Urk]

Cyphax schreef op maandag 20 juli 2020 @ 13:57:
[...]

Dan moet je even die = weghalen, die hoort daar niet thuis. Maar dan nog krijg je volgens mij niet je gewenste volgorde.
De vraag is: wat is de logica achter jouw gewenste volgorde en kan je die in SQL uitdrukken (het is niet willekeurig) mbv andere kolommen, of eventueel op een andere manier? Anders zul je ze los moeten ophalen.

Oh ja, tuurlijk, stom...... Het werkt nu wel maar precies zoals jij al zegt, de volgorde van de records veranderd idd niet...
Ja met een UNION kan ik nog proberen, het zijn namelijk altijd max 5 records

[Urk]

scatman schreef op maandag 20 juli 2020 @ 13:05:
Via een omweg gaat dit wel:

code:

select 1, * from products where Id=4
Union
Select 2, * from products where id=3
Union
...
Order by 1

Thanks , dit werkt inderdaad prima, alleen is de query normaal al vrij groot en nu dus 5 keer zo groot

[Orion84]

Maar waarom is die volgorde zo belangrijk? Ik neem aan dat je in je code een en ander opslaat in een of ander soort lijst van product objecten. Dan kan je toch gewoon door die lijst lopen en dan per product een query uitvoeren om de eigenschappen van dat product op te halen?

[CurlyMo]

Ik vermoed dat dit ook een gevalletje XY-probleem is

TS, lees eens wat er met XY-probleem probleem wordt bedoelt en kijk of je je erin herkent.

[Urk]

Orion84 schreef op maandag 20 juli 2020 @ 14:05:
Maar waarom is die volgorde zo belangrijk? Ik neem aan dat je in je code een en ander opslaat in een of ander soort lijst van product objecten. Dan kan je toch gewoon door die lijst lopen en dan per product een query uitvoeren om de eigenschappen van dat product op te halen?

Ja, klopt, alles wordt omgezet naar een 2D List<> in C#.

Het is A nodig omdat ik wil dat het eerste product wat een bezoeker kiest om te vergelijken ook als eerste in de meest linker kolom verschijnt.
De vergelijk URL die ik aanroep bijv is iets zoals: domein.nl/vergelijken/7341/7317/7386/7406/7011
En B omdat de query die erna komt voor de eigenschappen ook al in deze volgorde uitvoer.

Ik weet dat ik wellicht de LIST weer kan sorteren maar wil de code zo kort en overzichtelijk mogelijk houden. Als ik bovenstaande query zo oplos is het helemaal OK

[Tsurany]

Urk schreef op maandag 20 juli 2020 @ 13:57:
[...]

Ja, daar ben ik het opzich wel mee eens, ik had al een idee de andere query gewoon van laag naar hoog uit te voeren en deze dan ook. Echter als ik het in SQL op een makkelijke manier kan doen heeft dat de voorkeur

Dat heeft eigenlijk nooit de voorkeur. Je gaat nu presentatielogica afhandelen in je database in plaats van in de applicatie waarin je die presentatie verzorgd. Dat heet spaghetticode, uiteindelijk weet niemand weer wat nu in welk stuk gerealiseerd wordt en hoe alles aan elkaar hangt.

[Cyphax]

Urk schreef op maandag 20 juli 2020 @ 14:10:
[...]

Ja, klopt, alles wordt omgezet naar een 2D List<> in C#.

Het is A nodig omdat ik wil dat het eerste product wat een bezoeker kiest om te vergelijken ook als eerste in de meest linker kolom verschijnt.
De vergelijk URL die ik aanroep bijv is iets zoals: domein.nl/vergelijken/7341/7317/7386/7406/7011
En B omdat de query die erna komt voor de eigenschappen ook al in deze volgorde uitvoer.

Ik weet dat ik wellicht de LIST weer kan sorteren maar wil de code zo kort en overzichtelijk mogelijk houden. Als ik bovenstaande query zo oplos is het helemaal OK

Dat klinkt (maar het is in het wilde weg ) alsof je ergens zou moeten opslaan welke volgorde de bezoeker die paginas geraadpleegd heeft (in een cookie ofzo). Verplaats het weergeven in de goede volgorde vanuit de database naar je applicatie.

[Orion84]

Urk schreef op maandag 20 juli 2020 @ 14:10:
[...]

Ja, klopt, alles wordt omgezet naar een 2D List<> in C#.

Het is A nodig omdat ik wil dat het eerste product wat een bezoeker kiest om te vergelijken ook als eerste in de meest linker kolom verschijnt.
De vergelijk URL die ik aanroep bijv is iets zoals: domein.nl/vergelijken/7341/7317/7386/7406/7011
En B omdat de query die erna komt voor de eigenschappen ook al in deze volgorde uitvoer.

Ik weet dat ik wellicht de LIST weer kan sorteren maar wil de code zo kort en overzichtelijk mogelijk houden. Als ik bovenstaande query zo oplos is het helemaal OK

Maar waarom alles in één query proberen te frotten waarbij het resultaat van die query de volgorde van presenteren bepaalt?

Maak gewoon in je code een lijst aan op basis van de parameters van de pagina die wordt aangeroepen. En loop dan in je code door die lijst heen en voor elk product in de lijst voer je de benodigde query/queries uit om de eigenschappen van dat product op te vissen.

[Urk]

CurlyMo schreef op maandag 20 juli 2020 @ 14:07:
Ik vermoed dat dit ook een gevalletje XY-probleem is

TS, lees eens wat er met XY-probleem probleem wordt bedoelt en kijk of je je erin herkent.

Ja, dat zou zeker best eens kunnen maar ik wil het gewoon makkelijk kunnen oplossen. Tuurlijk zou ik weer helemaal opnieuw kunnen beginnen, dat heb ik zelfs al 2 keer gedaan met dit stuk code omdat ik tegen zaken aanliep die niet konden of niet goed gingen. Het grote probleem met een vergelijk functie is al dat je de eigenschappen naast elkaar moet hebben en niet onder elkaar en daardoor je SQL output al anders moet opbouwen.

[Urk]

Tsurany schreef op maandag 20 juli 2020 @ 14:10:
[...]

Dat heeft eigenlijk nooit de voorkeur. Je gaat nu presentatielogica afhandelen in je database in plaats van in de applicatie waarin je die presentatie verzorgd. Dat heet spaghetticode, uiteindelijk weet niemand weer wat nu in welk stuk gerealiseerd wordt en hoe alles aan elkaar hangt.

Of ik het nou in m'n SQL query sorteer of in m'n C# code heeft voor mij hetzelfde resultaat. Sterker nog: liever doe ik het met SQL met een -indien mogeiljk- kleine query aanpassing dan weer de nodige regels c# te moeten schrijven en testen terwijl ik al dicht bij de oplossing zit.

[Orion84]

Urk schreef op maandag 20 juli 2020 @ 14:13:
[...]

Ja, dat zou zeker best eens kunnen maar ik wil het gewoon makkelijk kunnen oplossen. Tuurlijk zou ik weer helemaal opnieuw kunnen beginnen, dat heb ik zelfs al 2 keer gedaan met dit stuk code omdat ik tegen zaken aanliep die niet konden of niet goed gingen. Het grote probleem met een vergelijk functie is al dat je de eigenschappen naast elkaar moet hebben en niet onder elkaar en daardoor je SQL output al anders moet opbouwen.

Zoals Tsurany ook al zegt: stap één hier is het loskoppelen van presentatielogica van je data.

[Urk]

Cyphax schreef op maandag 20 juli 2020 @ 14:12:
[...]

Dat klinkt (maar het is in het wilde weg ) alsof je ergens zou moeten opslaan welke volgorde de bezoeker die paginas geraadpleegd heeft (in een cookie ofzo). Verplaats het weergeven in de goede volgorde vanuit de database naar je applicatie.

Nee, de bezoeker klikt gewoon in een productoverzicht een vergelijk icoontje aan of uit. Als hij aanstaat is dat de eerste product_id die wordt opgeslagen, als eraan wordt toegevoegd komen die erbij. Als er een vergelijk icoontje wordt uitgezet valt die er tussenuit, wordt hij daarna weer aangezet komt hij achteraan in de rij

[Hydra]

Urk schreef op maandag 20 juli 2020 @ 13:55:
Dank je, maar deze query accepteert SQL niet, krijg de volgende error:
Incorrect syntax near the keyword 'IN'.

Ik doe het uit m'n hoofd he, zit gewoon een typo in. Beetje research doen

[Hydra]

Tsurany schreef op maandag 20 juli 2020 @ 14:10:
[...]

Dat heeft eigenlijk nooit de voorkeur. Je gaat nu presentatielogica afhandelen in je database in plaats van in de applicatie waarin je die presentatie verzorgd. Dat heet spaghetticode, uiteindelijk weet niemand weer wat nu in welk stuk gerealiseerd wordt en hoe alles aan elkaar hangt.

Nouja dat is ook niet helemaal zo. Het is doodnormaal normaliter om sortering in je database te doen. Probleem hier is puur dat hij wil sorteren op een arbitraire volgorde die de database niet 'kent'. Dan zijn er twee opties; zorgen dat via de query de database die info wel heeft (via union of join), of het gewoon in de code te doen. Dat laatste schaalt natuurlijk alleen bij relatief kleine lijsten.

[Urk]

Hydra schreef op maandag 20 juli 2020 @ 14:22:
[...]


Nouja dat is ook niet helemaal zo. Het is doodnormaal normaliter om sortering in je database te doen. Probleem hier is puur dat hij wil sorteren op een arbitraire volgorde die de database niet 'kent'. Dan zijn er twee opties; zorgen dat via de query de database die info wel heeft (via union of join), of het gewoon in de code te doen. Dat laatste schaalt natuurlijk alleen bij relatief kleine lijsten.

Ik wou dit net ook zeggen inderdaad, anders zou niemand ooit een ORDER BY clause nodig hebben.
Ik ben het natuurlijk met iedereen eens dat dit wellicht beter in de C# code te doen, dat wilde ik eigenlijk ook doen maar ben al veel te lang met deze functie bezig omdat ik steeds weer tegen een andere uitdaging aanloop. Dit was de laatste horde te nemen, dus... Ik zie hier ook verder het probleem niet zo van, zeker niet als de query net zo snel uitvoert als zonder sortering.

[Urk]

coop schreef op maandag 20 juli 2020 @ 13:04:
Dit zou moeten werken. Moet je wel zelf de volgorde meegeven in de ORDER BY.

code:

SELECT products.* WHERE product_actief = 1 AND product_id IN (7341, 7317, 7386, 7406, 7011) ORDER BY CASE WHEN product_id = 7341 THEN 1 WHEN product_id = 7317 THEN 2 WHEN product_id = 7386 THEN 3 WHEN product_id = 7406 THEN 4 WHEN product_id = 7011 THEN 5 Else product_id END ASC

Tevens is x IN () meestal sneller dan meerdere ORs, maar dat is afhankelijk van het aantal mogelijkheden.

Dit werkt idd prima en is ook nog wel makkelijk te bouwen door deze query dynamisch op te bouwen met parameters

[Tsurany]

Hydra schreef op maandag 20 juli 2020 @ 14:22:
[...]


Nouja dat is ook niet helemaal zo. Het is doodnormaal normaliter om sortering in je database te doen. Probleem hier is puur dat hij wil sorteren op een arbitraire volgorde die de database niet 'kent'. Dan zijn er twee opties; zorgen dat via de query de database die info wel heeft (via union of join), of het gewoon in de code te doen. Dat laatste schaalt natuurlijk alleen bij relatief kleine lijsten.

Sorting is natuurlijk redelijk standaard maar wat je nu wilt is sorteren op basis van user input. Wil je dan elke keer de query opnieuw uitvoeren als een user een extra product toevoegt? Of als een user net een andere volgorde wilt?

Dit lijkt me heel makkelijk in je front-end af te handelen.

[Cyphax]

Urk schreef op maandag 20 juli 2020 @ 14:19:
[...]

Nee, de bezoeker klikt gewoon in een productoverzicht een vergelijk icoontje aan of uit. Als hij aanstaat is dat de eerste product_id die wordt opgeslagen, als eraan wordt toegevoegd komen die erbij. Als er een vergelijk icoontje wordt uitgezet valt die er tussenuit, wordt hij daarna weer aangezet komt hij achteraan in de rij

Dat bedoel ik; aan de hand van die gegevens weet je toch de volgorde?

[Urk]

Cyphax schreef op maandag 20 juli 2020 @ 14:30:
[...]

Dat bedoel ik; aan de hand van die gegevens weet je toch de volgorde?

Ja, dat klopt inderdaad. Ik zou nog eens kunnen kijken of ik daar makkelijk iets mee kan doen maar waarom moeilijk doen als het nu ook al werkt door de query iets aan te passen met al jullie hulp en feedback

[Urk]

Tsurany schreef op maandag 20 juli 2020 @ 14:30:
[...]

Sorting is natuurlijk redelijk standaard maar wat je nu wilt is sorteren op basis van user input. Wil je dan elke keer de query opnieuw uitvoeren als een user een extra product toevoegt? Of als een user net een andere volgorde wilt?

Dit lijkt me heel makkelijk in je front-end af te handelen.

Ja, dat gebeurd uberhaupt al. Als een product wordt toegevoegd en je komt terug op de vergelijk pagina wordt de query natuurlijk weer opnieuw uitgevoerd, maar lijkt me redelijk logisch toch? De volgorde zelf aanpassen laat ik niet toe via de GUI, alleen eventueel via de URL als een bezoeker dat zou willen maar ik ga er geen functionaliteit voor inbouwen

[Tsurany]

Urk schreef op maandag 20 juli 2020 @ 14:33:
[...]

Ja, dat gebeurd uberhaupt al. Als een product wordt toegevoegd en je komt terug op de vergelijk pagina wordt de query natuurlijk weer opnieuw uitgevoerd, maar lijkt me redelijk logisch toch?

Hangt er vanaf, je kan dit natuurlijk in principe gewoon cachen in de browser en dan enkel de nieuwe producten ophalen. Hangt natuurlijk af van de schaal waarop je dit wilt doen.

De volgorde zelf aanpassen laat ik niet toe via de GUI, alleen eventueel via de URL als een bezoeker dat zou willen maar ik ga er geen functionaliteit voor inbouwen

Waarom dan geen default sort by id?

[Hydra]

Tsurany schreef op maandag 20 juli 2020 @ 14:30:
Sorting is natuurlijk redelijk standaard maar wat je nu wilt is sorteren op basis van user input. Wil je dan elke keer de query opnieuw uitvoeren als een user een extra product toevoegt?

Je moet de data ook ophalen, dus why not. Dit zijn ook niet bepaald zware queries. in de front-end dingen cachen heeft ook weer z'n issues.

Dit lijkt me heel makkelijk in je front-end af te handelen.

Ik zou dit in dit geval ook in de front-end doen, omdat het een korte lijst is. Maar als je iets als dit wil doen en ook wil kunnen pagen, dan moet je het sowieso al in de DB doen.

Dit is gewoon een heel specifiek issue waarbij er meerdere wegen naar Rome leiden.

[Urk]

Hydra schreef op maandag 20 juli 2020 @ 14:36:
[...]
Dit is gewoon een heel specifiek issue waarbij er meerdere wegen naar Rome leiden.

Dank je en Amen
Maar natuurlijk wel fijn zoveel input te krijgen en te zien of het allemaal niet beter/sneller kan natuurlijk.

[ Voor 20% gewijzigd door Urk op 20-07-2020 14:38 ]

[Hydra]

Urk schreef op maandag 20 juli 2020 @ 14:38:
Dank je en Amen
Maar natuurlijk wel fijn zoveel input te krijgen en te zien of het allemaal niet beter/sneller kan natuurlijk.

Je primaire concern is onderhoudbaarheid. Je weet in je front-end al de volgorde van die IDs dus je kunt daar heel simpel de uiteindelijke productlist op sorteren. Dat is veruit de oplossing met de minste hoeveelheid code. Met "er leiden meerdere wegen naar Rome" bedoel ik niet dat ik dit net zo'n goeie oplossing vindt. Ik had dit zelf gewoon herschreven.

[The Eagle]

Nvm

[ Voor 93% gewijzigd door The Eagle op 20-07-2020 14:53 ]

[Cyphax]

Urk schreef op maandag 20 juli 2020 @ 14:32:
[...]

Ja, dat klopt inderdaad. Ik zou nog eens kunnen kijken of ik daar makkelijk iets mee kan doen maar waarom moeilijk doen als het nu ook al werkt door de query iets aan te passen met al jullie hulp en feedback

In eerste instantie om wat @Hydra ook al opmerkt: het is niet de meest logische plek om de volgorde in te bepalen. Dat geeft risico dat je op een later moment (dat kan jaren zijn) moet zoeken hoe je dat toen ook al weer had opgelost, en minder risico dat jouw oplossing op later moment in de weg gaat zitten.
Soms lijkt het op moeilijk doen, maar uiteindelijk wordt de applicatie er beter van.

[The Eagle]

Ik ga er vanuit dat dit onderdeel is vn een groter geheel? Dan zou ik als developer niet die volgorde gaan bepalen, maar aan de PO terugvragen of ie daar uberhaupt een volgordelijkheid in wil.
En bedenk je ook dat je meestal maar max 3 tot 5 producten vergelijkt op een webpagina, anders wordt het vrij snel vrij onoverzichtelijk

Last: wil je het toc zelf bepalen, de description van het product ook ophalen en daar op sorteren, gaat ie op alfabet. Dat werkt voor ieder mens intuïtief.

[Urk]

The Eagle schreef op maandag 20 juli 2020 @ 18:04:
Ik ga er vanuit dat dit onderdeel is vn een groter geheel? Dan zou ik als developer niet die volgorde gaan bepalen, maar aan de PO terugvragen of ie daar uberhaupt een volgordelijkheid in wil.
En bedenk je ook dat je meestal maar max 3 tot 5 producten vergelijkt op een webpagina, anders wordt het vrij snel vrij onoverzichtelijk

Last: wil je het toc zelf bepalen, de description van het product ook ophalen en daar op sorteren, gaat ie op alfabet. Dat werkt voor ieder mens intuïtief.

Wat bedoel je met PO? Ik ken het alleen als Purchase Order maar dat bedoel je vast niet....
Ja, het max aantal producten is nu sowieso al 5.

[ Voor 4% gewijzigd door Urk op 20-07-2020 18:13 ]

[RobIII]

scatman schreef op maandag 20 juli 2020 @ 13:05:
Via een omweg gaat dit wel:

code:

select 1, * from products where Id=4
Union
Select 2, * from products where id=3
Union
...
Order by 1

SQL:

SELECT *, case 
    when product_id = 7341 then  1
    when product_id = 7317 then  2
    when product_id = 7386 then  3
    when product_id = 7406 then  4
    when product_id = 7011 then  5
    end as ord
FROM products
WHERE product_id IN (7341,7317,7386,7406,7011)
ORDER BY ord

En zo zijn er nog wat andere 'creatieve' oplossingen. Maar zoals anderen al aangegeven: dit wil je niet in je query/database oplossen maar in je presentatielaag.

Edit: oh, ik zie nu coop in "[SQL] Query op product ID's maar sortering niet juist" pas. Dat is min-of-meer 'tzelfde.

Urk schreef op maandag 20 juli 2020 @ 18:13:
Wat bedoel je met PO?

Product Owner

coop schreef op maandag 20 juli 2020 @ 13:04:
Tevens is x IN () meestal sneller dan meerdere ORs, maar dat is afhankelijk van het aantal mogelijkheden.

offtopic:
Ik kan 't niet hard maken en heb 't niet gebenchmarked noch heb ik daar nu zin in ( ) maar... dat lijkt me stug. Een IN(...) is niks anders dan een ... X = A OR X = B OR X = C ...; als je queryplanner c.q. optimizer dat al niet ziet.... dan is 't vast MySQL
Misschien in bepaalde edge-cases, maar door de bank genomen lijkt 't me stug als 't verschil maakt.

Edit: Mijn eerste google hit lijkt dat te bevestigen - maar er zijn ook wel wat hits die wat edge-cases hebben gedocumenteerd waar er een (miniem) verschil is.

[ Voor 65% gewijzigd door RobIII op 20-07-2020 18:28 ]

[Josk79]

In MySQL kun je

code:

ORDER BY FIELD(product_id, 7341,7317,7386,7406,7011)

doen, maar ik weet niet of MSSQL een equivalent heeft.

[pedorus]

Volgens mij niet, maar alsnog geef je dan de ids 2x door. Je kunt ook een hulptabelletje gebruiken in de query. Zoiets:

SQL:

select products.* from 
(values (7341,1),(7317,2),(7386,3),(7406,4),(7011,5)) as idxs(id,idx)
join products on idxs.id=products.product_id
where product_actief=1
order by idxs.idx;

Getest op https://dbfiddle.uk/?rdbm...ec6c72a7e1c0ca0edf1d93f69

[coop]

RobIII schreef op maandag 20 juli 2020 @ 18:13:
[...]

offtopic:
Ik kan 't niet hard maken en heb 't niet gebenchmarked noch heb ik daar nu zin in ( ) maar... dat lijkt me stug. Een IN(...) is niks anders dan een ... X = A OR X = B OR X = C ...; als je queryplanner c.q. optimizer dat al niet ziet.... dan is 't vast MySQL
Misschien in bepaalde edge-cases, maar door de bank genomen lijkt 't me stug als 't verschil maakt.

Edit: Mijn eerste google hit lijkt dat te bevestigen - maar er zijn ook wel wat hits die wat edge-cases hebben gedocumenteerd waar er een (miniem) verschil is.

offtopic:
Er zijn ook genoeg Google hits die bevestigen dat er zeker een snelheidsverschil is tussen ORs en IN. Tot 30% bij grotere datasets. Maar dat is inderdaad zonder goeie optimizer en in MySQL, mijn opmerking was dan ook voor OP gemeld had wat voor database hij gebruikt. Maar goed, je kan op Google vinden wat je wilt, afhankelijk van de search query. Wellicht iets te snel gezegd en te stellig verwoord.

[ Voor 5% gewijzigd door coop op 20-07-2020 21:56 ]

[The Eagle]

Urk schreef op maandag 20 juli 2020 @ 18:13:
[...]

Wat bedoel je met PO? Ik ken het alleen als Purchase Order maar dat bedoel je vast niet....
Ja, het max aantal producten is nu sowieso al 5.

Product Owner. Degene die je het systeem laat bouwen en je vertelt wat ie wil hebben. Kortom: hij die bepaalt

[Gomez12]

RobIII schreef op maandag 20 juli 2020 @ 18:13:
[...]
En zo zijn er nog wat andere 'creatieve' oplossingen. Maar zoals anderen al aangegeven: dit wil je niet in je query/database oplossen maar in je presentatielaag.

Dat vind ik toch wel heel erg afhankelijk van de use-case...

Hier hebben we een export-systeem waaruit een klant exports kan samenstellen en de gemiddelde klant-selectie omvat dan ook 1 miljoen+ id's.
Toen zijn we bij opbouw van het systeem toch al heel snel bij temp-tabellen gevuld met id's uitgekomen omdat je naast het joinen op die temp-tabel je ook additionele velden voor bijv sortering oid mee kan geven die vanaf dat moment ook in de database staan (hoe vluchtig dan ook)

Maar zolang je grofweg onder de 500 items blijft zou ik je gelijk geven...

[...]
[ot]Ik kan 't niet hard maken en heb 't niet gebenchmarked noch heb ik daar nu zin in ( ) maar... dat lijkt me stug. Een IN(...) is niks anders dan een ... X = A OR X = B OR X = C ...; als je queryplanner c.q. optimizer dat al niet ziet.... dan is 't vast MySQL
Misschien in bepaalde edge-cases, maar door de bank genomen lijkt 't me stug als 't verschil maakt.

Uiteraard ook hier niet gebenchmarked of zin daarin, maar theoretisch kan een in sneller zijn omdat een in simpelweg meer informatie in zich heeft dan een or.
Met een in weet de optimizer dat het altijd uit dezelfde tabel en zelfs hetzelfde veld komt, oftewel hij zou theoretisch de waardes van de in kunnen sorteren naargelang de sorteerindex die hij gaat kiezen voor die tabel/dat veld. Waardoor het net een table/index-scan kan vermijden...

Alleen nog theoretischer valt dat ook wel weer uit te rekenen voor een setje or-statements.

Alleen op het moment dat je het van dat soort optimalisaties moet gaan hebben, dan heb je hele andere problemen...

[Rensjuh]

Urk schreef op maandag 20 juli 2020 @ 13:17:
[...]

Sorry, slordig dat ik dat natuurlijk niet heb vermeld. Het betreft Microsoft SQL Server 2016.
product_id = Integer

Wat ik hiermee wil bereiken: dit is een query die wordt gebruikt in een product vergelijk functie. Aangezien er na deze query en een 2e query wordt uitgevoerd om alle producteigenschappen op te halen en deze door de nodige subquery wel in deze volgorde is te doen moet de eerste query daar natuurlijk wel op aansluiten.

Is dit zo ingewikkeld dat je niet gewoon een JOIN kunt gebruiken om de eigenschappen op te halen?