[SQL] Probleem met ordenen van (string)maten

[Fusioxan]

Goede ochtend,

Op dit moment ben ik bezig met een webshop te verbeteren. De klant wil dat de maten die zij opgeeft oplopend worden geordend.Het probleem is, de optienamen staan als string in de database en niet als integer, omdat het dezelfde tabel is voor onder andere kleuren.

Dus ik dacht, als ik dan ORDER BY `kolomnaam` ASC doe, loopt het ook nog goed met de kleuren. Helaas is volgens SQL 140 × 80 kleiner als 80 × 80, omdat een 1 kleiner is als een 8. Dus ik ging verder met de prijs van de optie, omdat iets kleiner ook goedkoper is. Alleen, sommige opties kosten evenveel, terwijl het wel andere maten zijn. Ik kon het gedeeltelijk oplossen met ORDER BY `OPTIEPRIJS` ASC, 'OPTIENAAM' ASC, maar dan vind hij nog steeds dan 140 kleiner is als 80.

Na wat nadenken, zou ik eventueel voor prijzen een ander teken dan 'x' kunnen gebruiken, bijvoorbeeld '|'. Vervolgens kijken in de webshop of het teken '|' er in voorkomt, zo ja exploden en ordenen op de juiste grote. Echter denk ik dat dit een best grote omweg is naar wat ik wil.

Kort samengevat, hoe kan ik maten die als string in de database staat ordenen als een integer, terwijl er ook nog kleuren in dezelfde kolom (wel in een andere rij) staan?

Alvast bedankt!

[ThinkPad]

Heb je ze random in de database staan? Of van klein naar groot ingevoerd? Anders kan je wel een ORDER BY doen op de ID van de maat lijkt mij? (Ik weet niet hoe je tabellen eruitzien?)

[Redshark]

Als je alle maten op die manier hebt opgeslagen zou je kunnen overwegen om te kijken naar het eerste woord in die kolom. Dit geldt dan wel specifiek voor alleen deze producten c.q. eigenschappne en lijkt mij derhalve niet heel netjes. Werken zal het wellicht wel.

[NMe]

Maten in een aparte tabel zetten met vervolgens een extra veld voor de sorteervolgorde lijkt me de makkelijkste oplossing. Je zegt dat je in hetzelfde veld ook kleuren opslaat, maar die zouden ook best naar dezelfde tabel kunnen en ook gebruik kunnen maken van dat nieuwe veld voor de sorteervolgorde.

[Fusioxan]

ThinkPadd schreef op woensdag 13 juli 2011 @ 11:26:
Heb je ze random in de database staan? Of van klein naar groot ingevoerd? Anders kan je wel een ORDER BY doen op de ID van de maat lijkt mij? (Ik weet niet hoe je tabellen eruitzien?)

Dit zou een optie kunnen zijn. Helaas moet ze dan alles overtypen als ze nog een kleinere maat heeft ingekocht. Bijvoorbeeld: In de database staan de maten 140 × 90, 140 × 100, 140 × 120, 140 × 190, 240 × 90, 240 × 120 al. Ze koopt een nieuwe maat in, 120 × 200. Dus moet ze alles 1 kolom naar beneden overtypen, omdat het anders niet meer kan.

Redshark schreef op woensdag 13 juli 2011 @ 11:36:
Als je alle maten op die manier hebt opgeslagen zou je kunnen overwegen om te kijken naar het eerste woord in die kolom. Dit geldt dan wel specifiek voor alleen deze producten c.q. eigenschappne en lijkt mij derhalve niet heel netjes. Werken zal het wellicht wel.

Dit zou een vieze oplossing kunnen zijn. Ik heb dan wel het eerste woord/breedte maat, maar hoe sorteer ik dan op de lengtemaat?

NMe schreef op woensdag 13 juli 2011 @ 11:42:
Maten in een aparte tabel zetten met vervolgens een extra veld voor de sorteervolgorde lijkt me de makkelijkste oplossing. Je zegt dat je in hetzelfde veld ook kleuren opslaat, maar die zouden ook best naar dezelfde tabel kunnen en ook gebruik kunnen maken van dat nieuwe veld voor de sorteervolgorde.

Hmm, ik denk dat ik juist in dezelfde tabel een veld erbij maak met de sorteervolgorde die een integer bevat voor de sorteervolgorde zoals je al zegt. Ik denk dat ik in het adminpaneel er dan meteen drag-and-drop of met pijltjes ga werken voor de volgorde.

Bedankt voor jullie input!

[lier]

Waarom is gekozen om één veld in de database op te nemen dat zowel geschikt is voor afmetingen als voor kleur?
Als je al een wijziging doet, neem dan (voor afmetingen) in ieder geval twee velden op (lengte en breedte).

Misschien ook eens kijken of de database (verder) genormaliseerd kan worden!?

[NMe]

lier schreef op woensdag 13 juli 2011 @ 11:54:
Waarom is gekozen om één veld in de database op te nemen dat zowel geschikt is voor afmetingen als voor kleur?

Gebeurt wel vaker hoor, vooral bij postorderbedrijven die van alles verkopen, van tv's tot matrassen, van kleren tot games. En allemaal hebben ze wel een apart soort kenmerk dat je graag wil opnemen. Relationele databases komen in dat soort opzetten niet geweldig tot hun recht en je zal je in zo'n situatie vaak verdedigbaar beroepen op een "database-in-een-database"-model. Als je weet waarom je het toe moet passen en vooral ook als je weet waarom je het in andere situaties niet toe moet passen is dat meestal geen probleem.

[Fusioxan]

lier schreef op woensdag 13 juli 2011 @ 11:54:
Waarom is gekozen om één veld in de database op te nemen dat zowel geschikt is voor afmetingen als voor kleur?
Als je al een wijziging doet, neem dan (voor afmetingen) in ieder geval twee velden op (lengte en breedte).

Misschien ook eens kijken of de database (verder) genormaliseerd kan worden!?

Ik ben het met je eens dat dat een beter oplossing is. Helaas is dit al een (redelijk) grote webshop. Een product kan meerdere eigenschappen hebben, zoals kleur, maat, soort print. Daarbij komt ook nog dat het een webshop is in een CMS systeem. Als een klant van mij dus met een nieuwe soort eigenschap komt, zoals druk per cm² (bijvoorbeeld) moet er weer een nieuwe tabel worden aangemaakt met een andere structuur. Ik kan zelfs beter een database-in-een-database bouwen dan een aparte tabel, omdat het andere minder efficiënt is dan de database-in-een-database.

[RobIII]

Fusioxan schreef op woensdag 13 juli 2011 @ 12:16:
omdat het andere minder efficiënt is dan de database-in-een-database.

Definieer efficiënt
Want een aparte tabel met velden die corrosponderen met de juiste eigenschappen die de juiste datatypes hebben zijn (uiteindelijk) natuurlijk altijd beter/efficiënter. Dat ondervind je nu zelf ook nu je op je bek gaat bij 't sorteren, maar dat ga je ook als je (bijvoorbeeld) iets zoekt met een afmeting van < 120cm breed of van >= 15kg of een productiedatum van na 2006-07-09 of... Als "alles" als strings/varchars is opgeslagen in "eigenschappentabellen" ga je daar altijd gezeik mee houden.

Neemt niet weg, wat NMe ook al zegt, dat 't soms wel te verdedigen is.

[ Voor 10% gewijzigd door RobIII op 13-07-2011 12:44 ]

[Macros]

Ik weet niet welke database je gebruikt maar voor oracle kan je dit gebruiken om te orderen:

SQL:

order by to_number(regexp_substr(optienaam, '\d+'))

Dat converteert het eerste getal in de string in een getal en geeft null als er geen getal is.
Hou wel in de gaten dat het bij grote aantallen nog wel snel blijft gaan. Dus van alle 500.000 objecten wil ik alleen de eerste 10 hierop gesorteerd, dat gaat waarschijnlijk niet performen.

Andere database implementaties hebben soortgelijke functies met misschien iets andere namen.

[ Voor 9% gewijzigd door Macros op 13-07-2011 17:28 ]

[NMe]

Je kan bij dat soort constructies meestal geen indexen gebruiken.

[Verwijderd]

Probleem is natuurlijk ook de vraag: "Wat is groot?"

Is 200 x 3 (gordijnroede) groter dan 190 x 80 (lattenbodem)?

[Voutloos]

Je moet inderdaad eerst duidelijk definieren hoe je de grootte beoordeelt, en denk dan ook aan de case waarbij iemand 10 x 9999 invult.

Als je definitie overeenkomt met het voorbeel van Macros, heb je een dergelijke order by binnen 2 minuten voor je specifieke dbms geschreven en kan je al testen af dat leuk werkt. Ivm het niet kunnen indexeren van de volgorde helpt het dan wel als je potentiele aantal rows een beetje leuk blijft.

[Gomez12]

Persoonlijk zou ik gewoon voor de extra tabel gaan met daarin de sorteervolgorde.

Met kleding heb je waarschijnlijk ook maten als XS / S / M / L / XL / XXL , veel plezier met daar een fatsoenlijke sortering op te verzinnen zonder hulptabel.
Je kan de meest ingenieuze algoritmes gaan verzinnen, maar zo goed als altijd blijft er wel een randgeval over...

[coldasice]

Als het een MS SQL is, copieer je de hele tabel naar excel en kun je met text naar kolommen, alles netjes ordenen, daarna samenvoegen. Een lijstje erachter zetten met 1,2,3......

Dan een extra kolom aanmaken in je tabel en het zaakje vanuit Excel te copieren in de Management Studio door een nieuwe row te selecteren en paste te klikken. Dat is eigenlijk hetzelfde als een BULKINSERT.

[ Voor 9% gewijzigd door coldasice op 13-07-2011 20:16 ]

[Verwijderd]

coldasice schreef op woensdag 13 juli 2011 @ 20:15:
Als het een MS SQL is, copieer je de hele tabel naar excel en kun je met text naar kolommen, alles netjes ordenen, daarna samenvoegen. Een lijstje erachter zetten met 1,2,3......

Neem dan wel een grotere interval dan 1, maar pak 10 of 100. Dan kan je makkelijker later maten (of kleuren of...) tussenvoegen zonder dat je zelf eerst de hele maattabel opnieuw moet sorteren.

[Xiphalon]

NMe schreef op woensdag 13 juli 2011 @ 18:06:
Je kan bij dat soort constructies meestal geen indexen gebruiken.

zolang de functies deterministisch zijn, kan een beetje database engine wel functies in een index gebruiken.

[coldasice]

Verwijderd schreef op woensdag 13 juli 2011 @ 20:30:
[...]


Neem dan wel een grotere interval dan 1, maar pak 10 of 100. Dan kan je makkelijker later maten (of kleuren of...) tussenvoegen zonder dat je zelf eerst de hele maattabel opnieuw moet sorteren.

Goeje tip

[Fusioxan]

Excuses dat ik niet gemeld had welke soort database ik heb, maar het gaat hier over een MySQK database. Ondertussen is het afgewerkt. Ik heb gekozen voor een extra veld met de volgorde-waarde. De klant (van ons, niet van de webshop) kan zelf product opties toevoegen, en deze vervolgens sorteren door het drag-and-drop principe. Zo kan er nooit iets fout gaan met verschillende gegevenstype. Toch nog bedankt!

[Big Womly]

Je getallen allemaal dezelfe lengte maken en vooraan aanvullen met "0"-en