[databases] waar de 'mogelijkheden' voor een veld opslaan?

[Ssander]

Ik zit erg te twijfelen over een bepaald probleem waar ik graag wat meningen en input over zou willen hebben. Ik ben bezig met een site waar bepaalde diensten worden aangeboden. Afhankelijk van welke dienst wordt gekozen (denk hierbij aan verhuizingen, schilderen, tuinieren) komt er een vragenformulier tevoorschijn. Deze vragen sla ik op in een MySQL database die ik benader met PHP. Ik heb de topictitel 'databases' genoemd omdat (volgens mij) dit probleem niet specifiek binnen PHP/MySQL bestaat. De tabel ziet er ruwweg als volgt uit (is eigenlijk groter, maar hier alleen de nodige info);

id	Primary Key / auto_increment
service_id	Type service, FK naar een andere DB
question	De daadwerkelijke vraag
question_type	Type vraag, bepaald hoe de input weergeven wordt (textarea, text input, checkbox, listbox/radio buttons, etc)
question_options	Eventueel de mogelijke opties afhankelijk van het type vraag. Ik moet nog bepalen hoe ik dit precies op ga slaan (overweeg nu gewoon simpel een array te serializen)

Probleem
Het probleem waar ik nu mee zit is dat ik me afvraag hoe ik de mogelijke opties voor question_type ga opslaan in de tabel. Hoe weet ik welke mogelijkheden er zijn? Ik zie hier een aantal mogelijkheden;

1. Opslaan als text, dus bv 'text', 'fulltext' (waarbij ik met 'fulltext' aan een textarea zit te denken), 'checkbox', 'listbox' etc. Het voordeel hiervan is dat het meteen duidelijk te zien is.
2. Mooier is, lijkt mij, om hier een integer op te slaan net als ik bij service_id gedaan heb. Dit linkt naar een tabel services waar informatie over de diensten is opgeslagen (bv tarieven). Bij services is het logisch om dan een aparte tabel te gebruiken omdat ik voor diensten nog veel extra informatie op moet slaan. Dat is dus de tweede optie: een integer gebruiken die linkt naar een andere tabel
3. Optie 3 is om ook een integer te gebruiken, maar de mogelijkheden vervolgens in een array in PHP op te slaan. Ik zou dus iets hebben als array(1 => 'text', 2 => 'fulltext', 3 => 'checkbox' ..) waarmee ik kan zien wat het type is.
4. Enums. Ik ben er nog niet helemaal achter wanneer Enums nou nuttig zijn om te gebruiken binnen MySQL. De data zit in de database zelf wat het moeilijk maakt om te bewerken wanneer nodig.

Mijn gedachten
Voor de question_type lijkt optie 2 me een overkill omdat er geen extra informatie nodig is zoals bij de services wel het geval is. Het voordeel van dit doen is echter wel dat het makkelijk terug te vinden is wat de opties zijn (minder makkelijk dan bij optie 1) en dat het eenvoudig is deze aan te passen. Ook is er makkelijk binnen MySQL security toe te voegen om te zorgen dat er alleen waarden worden toegevoegd die ook echt bestaan.

Optie 3 lijkt me handig omdat er geen extra tabel voor nodig is en minder ingewikkelde queries met joins (al is dat hier natuurlijk best te overzien) nodig zijn. Nadeel is wel dat er minder snel te zien is wat de opties zijn omdat je moet weten waar de array met mogelijkheden is (al zou het logisch zijn om dit in een common.php of constants.php oid. op te slaan). Wel is het, net als bij optie 2, makkelijk aan te passen. Nieuwe mogelijkheden zijn makkelijk toe te voegen.

Optie 1 geeft me om de één of andere reden gewoon een slecht gevoel. Het zou wel duidelijk zijn en het zou ook niet al te moeilijk zijn om nieuwe opties toe te voegen maar ik werk liever toch met integers. Het lijkt gewoon wat veiliger en 'cleaner'. Ik kan dit helaas niet al te goed beargumenteren.

Ik neig zelf naar optie 3, maar ook lijkt optie 4 me wel interessant al is het alleen al omdat ik nog nooit met Enums heb gewerkt binnen MySQL. Onder andere door deze post echter twijfel ik ook erg of het sowieso wel nuttig is;

http://ronaldbradford.com...r-not-to-enum-2006-01-22/

Dus
Dus mijn vraag: wie heeft hier ervaring mee? Wat is verstandig, en wat niet? Googlen naar dit probleem geeft me niets, eigenlijk vooral omdat ik de juiste keywords niet helemaal weet te vinden om iets nuttigs uit Google te halen. Wel ben ik op Tweakers de volgende topic tegengekomen maar ik hoop eigenlijk op een wat bredere discussie hierover;

[mysql] enum of een join

Wat ik namelijk ook zou willen vragen is om verder te kijken dan dit specifieke probleem en het ook wat algemener te bekijken: wanneer zou je welke optie gebruiken? Is Optie 3 de grootste bullshit ooit? Is Optie 4 de oplossing voor vrijwel alle problemen die hier op lijken? De grootste reden dat ik deze topic start is omdat ik simpelweg niets op google kan vinden, en dus hoop dat er een interessante discussie ontstaat waar niet alleen ik maar ook anderen iets aan hebben.

[ixi]

Ik zou voor enums gaan, gezien je maar een beperkt aantal soorten velden hebt en die waarschijnlijk niet vaak zullen wijzigen. Volgens mij worden enums intern opgeslagen als integers en heeft het dus minder overhead als een string opslaan, hoewel het qua gebruik hetzelfde is.

PHP arrays serializen doe ik zelf wel af en toe, maar alleen in specifieke gevallen waar ik nooit selects op de data hoef te doen en de data dus alleen in PHP gebruik en als het om een kortlopend project gaat. Erg mooi is het niet, maar vaak een stuk sneller om te maken en je bent minder gebonden aan een vast datamodel (wat ook eigenlijk niet erg mooi is, maar soms wel praktisch). Bijvoorbeeld voor korte enquetes met veel vragen waarbij de vragenlijst veel aanpassingen krijgt voordat hij live gaat. Alle wijzigingen kan ik dan aan de HTML kant doorvoeren zonder de database of PHP aan te passen.

Het mooist lijkt me om een aparte tabel te gebruiken voor de records die extra opties hebben: id (primary key), question_id, option_name en evt een sort of default. Als je veel dezelfde soorten dropdowns of optie-lijsten gaat gebruiken kun je wellicht nog voordeel halen uit het maken van een aparte optionlist tabel, hoewel je dan weer de keuze moet maken of je de id van de optionlist gaat opslaan in de question tabel of weer een aparte tabel...

[pedorus]

Als het hier daadwerkelijk om 3 of iets in die orde aan formuliertjes gaat, dan zou ik dat gewoon los coderen. Anders ben je een platform aan het ontwerpen, in plaats van de applicatie zelf. Dat risico is hier levensgroot aanwezig.

Verder lijkt het mij dat question_type typisch een enum is (vast aantal mogelijkheden die bijna nooit veranderen), en question_options typisch iets is voor een losse tabel. Als hierboven dus.

[GlowMouse]

Enum is het mooiste, totdat je een grote tabel hebt bij een site die eigenlijk altijd up moet zijn en je een type toe wilt voegen. Qua opslagruimte zijn een tinyint en een enum even groot.

[pedorus]

Hmm, ja, de implementatie in MySQL is nog beroerd...

[ Voor 0% gewijzigd door pedorus op 25-12-2009 13:36 . Reden: link verbeterd ;) ]

[GlowMouse]

goede link

Maar als je durft, kan het wel snel overigens.

ontopic leesvoer: http://www.mysqlperforman...tatype-for-status-feilds/

[Ssander]

pedorus schreef op vrijdag 25 december 2009 @ 02:36:
Als het hier daadwerkelijk om 3 of iets in die orde aan formuliertjes gaat, dan zou ik dat gewoon los coderen. Anders ben je een platform aan het ontwerpen, in plaats van de applicatie zelf. Dat risico is hier levensgroot aanwezig.

Op het moment zijn er 8 diensten aanwezig, en het zou goed kunnen dat er in de toekomst meer bij komen en het zou ook goed kunnen dat diensten verdwijnen of veranderen aangezien dit nog een beginnend bedrijf is. Wat ik wil maken is een systeem waarin het voor de klant makkelijk is om vragen toe te voegen, vragen te wijzigen en vragen te verwijderen. Ook moet het makkelijk zijn om diensten toe te voegen. Er moet dus eigenlijk geen tot heel weinig HTML gebruikt hoeven te worden.

Overigens ben ik dit systeem in mijn eigen tijd aan het maken als test project. Het zou kunnen dat het uiteindelijk wel gebruikt gaat worden, en ik bouw het ook met dat in gedachten, maar ik hoef dus geen rekening te houden met deadlines oid. waardoor ik gewoon lekker kan experimenteren en veel kan leren. Dat is het hoofddoel van dit project, al zou het wel heel gaaf zijn als het ook daadwerkelijk gebruikt gaat worden (kans 50-50).

@pedorus: de topic waar je naar linkt is er één uit 2004. Ik hoop dat er na 5 jaar wel iets veranderd is? Dat ga ik maar eens even uitzoeken...

@glowMouse: die laatste link is erg interessant! Eigenlijk precies het soort discussie wat ik zoek. Heel erg bedankt.

@ixi: bedankt voor je gedachten over question_options. Ik moet hier nog goed over nadenken.