[SQL] Product opties binair opslaan

[Anoniem: 99022]

Ik weet niet hoe ik mijn probleem moet beschrijven, en daarom is het ook lastig zoeken. Ik heb dit ooit op school geleerd maar dat is ruim 10 jaar terug dus ben het echt vergeten.

Ik wil bij een product diverse opties kunnen opslaan in 1 veld. Als voorbeeld een kleur:
Zwart = 1
Rood = 2
Wit = 4
Groen = 8

etc, als in het kleurenveld dan 12 staat kun je terug rekenen dat het product leverbaar is in groen en wit, bij 3 is het zwart of rood. Dit zullen jullie vast wel herkennen, maar ik weet hiervoor niet de juiste benaming en dat maakt het zoeken lastig.
Mijn vraag aan jullie is dus: Hoe noemen we dit, en is het ook mogelijk met een dergelijk veld een query uit te voeren om bijvoorbeeld alle rode producten te selecteren?
Bvd en alsnog een goed weekend!

[RobIII]

Flags. Bitpatterns. Bitmagic Dat soort gein.
En ja, dat kun je in een SQL query toepassen maar over 't algemeen probeer je daar toch vandaan te blijven. Wat als je straks meer dan 32 kleuren hebt bijvoorbeeld? Dan ga je al "af" met je integer en kom je aan 't uitwijken naar grotere datatypes maar ook daar houdt 't een keer op. In RDBMS land ben je doorgaans veel beter af met een koppeltabel. Mede omdat je bitfields erg onhandig zijn om te doorzoeken naar een specifieke value (dat zal altijd een full table scan met een evaluatie van je bitmask per record opleveren == traaaag) omdat je geen (gangbare) indices kunt gebruiken.

[ Voor 22% gewijzigd door RobIII op 20-02-2016 17:23 ]

[Anoniem: 99022]

Dank! Dat is hoe ik het eerder ook altijd deed. Zat ik toch op de goede weg

[Hydra]

Anoniem: 99022 schreef op zaterdag 20 februari 2016 @ 17:00:
Mijn vraag aan jullie is dus: Hoe noemen we dit, en is het ook mogelijk met een dergelijk veld een query uit te voeren om bijvoorbeeld alle rode producten te selecteren?

Dat kan maar daarop indexeren is enorm lastig. Het packen van booleans in een bitfield is iets wat je eigenlijk alleen doet als je hoeveelheid geheugen een limiterende factor is. In het geval van data storage wil je je data zo veel mogelijk netjes genormaliseerd opslaan. Oftewel: don't do it.

Edit: zeg maar wat Rob zeg.

[mcDavid]

Ik werk af en toe tegen een database aan waar iemand het een goed idee vond om dit toe te passen, en ik kan je zeggen, het is echt vreselijk. Je kunt helemaal _niets_ met die database zonder de bijbehorende documentatie er naast te hebben liggen. En die documentatie bestaat uiteraard uit niets meer dan een uitdraai van de method die deze velden parst.

Kortom mijn advies is: Houd het lekker human readable. Tenzij je echt een belangrijke reden hebt om 3 bits per record te willen besparen, misschien omdat je op een microcontroller werkt of zo.

[ACM]

mcDavid schreef op zondag 21 februari 2016 @ 10:12:
Kortom mijn advies is: Houd het lekker human readable. Tenzij je echt een belangrijke reden hebt om 3 bits per record te willen besparen, misschien omdat je op een microcontroller werkt of zo.

Hoewel ik het met je advies eens ben, is de besparing waarschijnlijk wel aanzienlijk groter. Per relatie moet er tenslotte een record in die koppeltabel komen en daar zitten waarschijnlijk ook nog twee indexen op. Dan heb je het al gauw over tientallen bytes per record vs 1 bit.

Desalniettemin is het alsnog vooral interessant als je echt geheugen moet besparen en doorzoekbaarheid niet relevant is. Daarnaast moet je dan op voorhand eigenlijk wel kunnen garanderen dat het totaal aantal opties niet voorbij een vast aantal groeit (bijv 32 of 64) en dat er in totaal weinig zijn of dat je bij een hoog aantal alsnog een hele hoge dekking tov de beschikbare opties hebt.
Als je bijvoorbeeld een bitmap van 1024 bits nodig gaat hebben en daar gemiddeld maar een paar opties in activeert, dan zal de koppeltabel juist wel minder ruimte in nemen. Maar als er gemiddeld zo'n 400-500 aan staan, dan is het weer wel (veel) compacter.

[mcDavid]

Volgens mij kun je in MySQL (en ongetwijfeld in andere dbms) gewoon queryen op een bitmask, dus ik denk dat het qua doorzoekbaarheid nog meevalt. Althans, zolang je dat aan een daarvoor geschreven functie over laat, maar ik zou die functie zelf niet willen schrijven.

[Hydra]

mcDavid schreef op maandag 22 februari 2016 @ 10:36:
Volgens mij kun je in MySQL (en ongetwijfeld in andere dbms) gewoon queryen op een bitmask, dus ik denk dat het qua doorzoekbaarheid nog meevalt. Althans, zolang je dat aan een daarvoor geschreven functie over laat, maar ik zou die functie zelf niet willen schrijven.

Er op kunnen queryen is nogal wat anders dan dat indexing ook werkt.

[pedorus]

Alle 'handige' bit operators bestaan inderdaad in Mysql, maar als het niet om uitzonderlijke optimalisatie gaat, dan zou ik er niet aan beginnen. Je ziet op een gegeven moment al aankomen dat er meer dan 32 kleuren gaan zijn, bijvoorbeeld. Of dat iemand bit operators niet snapt. Of dat je een framework wil gebruiken waarin dit onhandig is. Of dat je een index nodig hebt op bit x.

Mijn ervaring: dit lijkt een leuke optimalisatie, maar wordt later een refactoring.

[YakuzA]

En wat ga je doen als je per kleur een specifiek aantal leverbaar hebt:
2 groen, 1 rood etc
Of bepaalde kleuren gekoppeld aan bepaalde maten?

Dan moet je later toch naar een koppeltabel maken met aantallen per kleur.
Voor een standaard webwinkel denk ik dat je beter af bent met een koppeltabelletje.

[ Voor 9% gewijzigd door YakuzA op 22-02-2016 11:42 ]