[MySql] Multichoice veld opslaan in tabel

[Anoniem: 99022]

Hallo mensen,

ik ben bezig met een website over auto's, hier kunnen mensen een zoekveld opslaan.
Voorbeeld: Hatchback, Sedan, Stationwagon, Suv.

Dit veld is multiple choice. Er kunnen dus 1 of meer opties aangevinkt worden.

Hoe kan ik dit het beste opslaan in 1 veld?

Ik heb dit ooit geweten, maar ook ik word ouder Was iets met een binaire oplossing. Bijv:
Hatchback = 1
Sedan = 2
Stationwagon = 4
Suv = 8

Als ik dan bijv een 9 opsla in mijn veld, is de selectie een SUV en Hatchback. Kijk, ik snap hoe het moet, maar hoe implementeer ik dit ook alweer het beste (ook in mijn query's om te zoeken op mensen die bijv bepaalde opties aanvinkten). Het was iets met binaire switch e.d. maar ik ben de weg ff kwijt.

[Anoniem: 178962]

Keyword 1: Normaliseren
Keyword 2 (indien keyword 1 faalt): MySQL heeft ondersteuning voor een datatype met de naam "SET", die doet precies wat jij wil zonder dat je zelf hoeft te rekenen.

[Tharulerz]

Je kan dit perfect opslaan op de manier die jij zegt (een soort van binair dus), maar dat heeft een aantal nadelen.

Ten eerste, je kan nooit kijken naar enkel de aparte categorieën (alle mensen die een sedan kiezen), je moet altijd kijken naar de combinaties (alle mensen die een sedan kiezen maar geen hatchback en geen stationwagon en geen SUV).

Ten tweede is normaliseren ook performanter om achteraf je data terug op te halen.

[P.O. Box]

Tharulerz schreef op vrijdag 15 oktober 2010 @ 02:29:
Je kan dit perfect opslaan op de manier die jij zegt (een soort van binair dus), maar dat heeft een aantal nadelen.

Ten eerste, je kan nooit kijken naar enkel de aparte categorieën (alle mensen die een sedan kiezen), je moet altijd kijken naar de combinaties (alle mensen die een sedan kiezen maar geen hatchback en geen stationwagon en geen SUV).

Volgens mij is dat niet waar, adt kan prima...

wat wel een nadeel is (maar hier waarschijnlijk niet van toepassing), dat je niet heel veel categorieen kan hebben, want je zit zo aan maxint.

[CodeCaster]

Kijk hier eens

Een bigint geeft de mogelijkheid tot het opslaan van 64 categorieën. Lijkt me voorlopig voldoende, maar ik zou zelf toch kiezen voor een koppeltabel.

[Janoz]

Mysql kan dat wel met een bigint, maar wie gaat garanderen dat het platform dat de query resultaten interpreteert ook hetzelfde bereik heeft? Wanneer je bijvoorbeeld php in een 32 bits omgeving draait wordt een waarde die buiten het bereik van een 32 bits getal valt zomaar omgezet in een float. Dan ben je wel mooi je minst significante bits kwijt.

[Hydra]

CodeCaster schreef op vrijdag 15 oktober 2010 @ 10:27:
Kijk hier eens

Een bigint geeft de mogelijkheid tot het opslaan van 64 categorieën. Lijkt me voorlopig voldoende, maar ik zou zelf toch kiezen voor een koppeltabel.

Je bent dan echt met een hamer een schroef in de muur aan het rammen. Normaliseren die hap, klaar. Dit is gewoon een simpel geval van een 1-N relatie dus een extra tabel met categorieen is m.i. de enige logische weg.

[CodeCaster]

Dat je het niet wil snap ik, ik zeg alleen dat het kan.

Hydra schreef op vrijdag 15 oktober 2010 @ 11:18:
[...]


Je bent dan echt met een hamer een schroef in de muur aan het rammen. Normaliseren die hap, klaar. Dit is gewoon een simpel geval van een 1-N relatie dus een extra tabel met categorieen is m.i. de enige logische weg.

Ik geef toch ook aan dat een oplossing met een koppeltabel mijn voorkeur geniet?

[Apache]

CodeCaster schreef op vrijdag 15 oktober 2010 @ 11:40:
Dat je het niet wil snap ik, ik zeg alleen dat het kan.

[...]

Ik geef toch ook aan dat een oplossing met een koppeltabel mijn voorkeur geniet?

Dat is zoals gebakjes en een bakje groentjes voor een dikke vrouw neerzetten, welke van de 2 eet ze op denk je ...

topic starter heeft duidelijk affiniteit voor de bitwise oplossing, waarbij elke developer met 3 weken ervaring meteen zien dat die superfout is, maar vanwege zijn voorkeur en posts als de jouwe die hem gaat hij gegarandeerd voor de gebakjes!

@TS: Die bitwise oplossing is hier gewoon zeer, zeer, zeer fout, doe het niet en steek 1 uurtje meer werk in de goeie oplossing, je gaat het jezelf niet beklagen.

[Hydra]

CodeCaster schreef op vrijdag 15 oktober 2010 @ 11:40:
Ik geef toch ook aan dat een oplossing met een koppeltabel mijn voorkeur geniet?

Het is geen kwestie van 'voorkeur' m.i. De oplossing van de TS is gewoon fout, klaar. En ik vind dat 'wij' ook tegen iemand die duidelijk onervaren is gewoon moeten zeggen waar het op staat.

[CodeCaster]

En waar leer je het meest van, voorgekauwde dingen aannemen of zelf tegen beperkingen aanlopen die je niet had hoeven hebben als je iets langer had doorgedacht?

[Hydra]

CodeCaster schreef op vrijdag 15 oktober 2010 @ 12:34:
En waar leer je het meest van, voorgekauwde dingen aannemen of zelf tegen beperkingen aanlopen die je niet had hoeven hebben als je iets langer had doorgedacht?

Hou op man. In dit geval leer je het meest van mensen die je vertellen waarom iets een verkeerde oplossing is. Of zijn volgens jou informatica opleidingen en hoorcolleges ook waardeloos?

[CodeCaster]

Hydra schreef op vrijdag 15 oktober 2010 @ 13:12:
[...]


Hou op man. In dit geval leer je het meest van mensen die je vertellen waarom iets een verkeerde oplossing is. Of zijn volgens jou informatica opleidingen en hoorcolleges ook waardeloos?

Mag het één tikje rustiger? Zijn oplossing is niet "fout", het is wel een slechte oplossing. En er heeft in dit topic nog niemand verteld waarom het een slechte oplossing is, alleen dat er betere oplossingen zijn.

Ik hoop dat TS door die reacties geprikkeld wordt te gaan zoeken naar betere oplossingen of dat 'ie in ieder geval gaat uitzoeken waarom bitwise en kommagescheiden waarden in een database minder goede ideeën zijn, waar 'ie naar mijn mening tot nu toe zat hints naar heeft gekregen.

Dat bedoel ik met niet voorkauwen.