Archief - Opties bij een wagen opslaan in database

Ik heb een gedachtengang probleempje in verband met een MySQL database van een website waar ik aan bezig ben.

Het is een site waar wagens op staan en bij het toevoegen van een nieuwe wagen (of wijzigen van een bestaande) kunnen opties aangevinkt worden uit een lijst (airconditioning, parkeersensoren, ..). Die opties komen ook uit een tabel van de database. Later moet er ook bij de zoekfunctionaliteit gefilterd worden op die opties.

Optie 1:

Oorspronkelijk was het idee om een database te gebruiken met de volgende structuur.

Waarbij ik dan gewoon alle opties kan ophalen in een lijst, en als em ook in cars_options zou zitten aanvinken en met een join wel die search zou kunnen forceren. Maar bij het updaten van de specs van de wagens zoudt ge dan onmogelijk zomaar kunnen weten wanneer ge een insert/delete zoudt moeten doen van een row in cars_options.

Optie 2:

Dan was het idee om de options tabel te behouden, maar in plaats van cars_options gewoon een extra kolom in cars (hier niet getoond) waar door middel van een json encoded array/string de aangevinkte options>id werden bijgehouden. Heel gemakkelijk om weg te schrijven en uit te lezen leek mij. Maar hoe gaat ge dan de zoekfunctie implementeren?


--

Simpele vraag eigenlijk: Zijn dit de beste oplossingen die voorhanden zijn of is er ergens iets dat ik op het moment over het hoofd zie? Ik hoop het ten zeerste.

Zero Grav zei:

Optie 1:

Oorspronkelijk was het idee om een database te gebruiken met de volgende structuur.

Code:

options      cars_options
- id         - id (eigenlijk zelfs niet nodig als ik zo bekijk)
- option     - car_id
             - option_id

Waarbij ik dan gewoon alle opties kan ophalen in een lijst, en als em ook in cars_options zou zitten aanvinken en met een join wel die search zou kunnen forceren. Maar bij het updaten van de specs van de wagens zoudt ge dan onmogelijk zomaar kunnen weten wanneer ge een insert/delete zoudt moeten doen van een row in cars_options.

Klik om te vergroten...

Ge zou alle referenties naar de opties van die wagen kunnen deleten en terug invoeren bij update. Zo bespaarde u wel wat queries denk ik.

Zero Grav zei:

Optie 2:

Dan was het idee om de options tabel te behouden, maar in plaats van cars_options gewoon een extra kolom in cars (hier niet getoond) waar door middel van een json encoded array/string de aangevinkte options>id werden bijgehouden. Heel gemakkelijk om weg te schrijven en uit te lezen leek mij. Maar hoe gaat ge dan de zoekfunctie implementeren?
.

Klik om te vergroten...

Moeilijk En met veel queries / splitten van uw resultaten.

Optie 1 lijkt mij toch nog het beste. Zeker qua structuur en overzicht.

zowiezo optie 1
optie 2 is bad practice

Hmm, die extra query met gewoon een delete voor alle bestaande opties van car_id daar had ik nog niet eens bij stilgestaan adrianhates. Is inderdaad perfect doenbaar, en vrij logisch. En zonder die id maakt het eigenlijk niet uit dat ge veel inserts hebt, want er auto increment niets. Zo dom van mij!

Als er nog iemand anders een idee heeft, bring it on!

Ben niet zo goed in het logisch denken, maar als ik het goed begrijp wil jij een tabel waar je gegevens uit kan halen en een tabel waar je gegevens in kan steken die de gebruikers hebben ingevoerd?

Wat ik zou doen, waarschijnlijk compleet ernaast, is gewoon een tabel maken met uw default wagens (dus alle 'vaste gegevens' eigenlijk) en dan een tabel met de veranderlijke. Zo kan je uw formulier die je gebruikt om de gebruiker te tonen waar hij allemaal uit kan kiezen opbouwen aan de hand van die default tabel en wanneer hij het formulier effectief verstuurt komen alle gegevens terecht in die 'custom tabel'.

Neen, 't is inderdaad iets anders. Gebruikers kunnen zelf wagens toevoegen met bepaalde specs en dan gewoon daarbij ook nog uit een lijst van opties kiezen of die op de wagen aanwezig zijn. Alles is dus op zich veranderlijk, maar de opties komen wel uit een predefined list.