Meerdere wanneer dat noodzakelijk is ivm je database normalisatie.
In jouw voorbeeld 2 kun je meerdere genders aan een user 'hangen'. Ik kan me niet voorstellen dat dat noodzakelijk is, kan dus prima volgens voorbeeld 1.
In jouw geval zijn het allemaal eigenschappen van een persoon, daar is maar precies 1 mogelijkheid mogelijk voor geslacht, kleur ogen, etc.
Zodra de mogelijkheid bestaat dat een waarde 0 of meer dan 1 keer kan voorkomen, maak je een andere tabel aan.
Denk dan bijvoorbeeld aan "naam-zoon". Een gebruiker kan in theorie 0 tot 999 zonen hebben.
Meerdere wanneer dat noodzakelijk is ivm je database normalisatie.
Grappig dat je het woord 'normalisatie' noemt. In voorbeeld 1 wordt namelijk een enum gebruikt, en als er iets is dat zo ongeveel alle normalisatieregels overtreedt, dan is dat wel een enum. Daarmee sla je namelijk data die eigenlijk in je databasevelden hoort te zitten op in de metadata van de tabel.
Is dat een probleem? Ja, dat is een probleem. ;-) Als je namelijk een optie wilt toevoegen of verwijderen, moet daarvoor je complete tabel opnieuw worden gebouwd. Vanwege een soortgelijke grap heb ik een database wel eens een paar uur offline gehad (was een erg grote tabel, dat wel).
Een ander punt is dat wanneer je een keuzelijst wilt vullen, je niet simpelweg een 'select name from gender' kunt doen. Je moet dan kunstgrepen uithalen als 'show create table' en die output parsen. Uiteraard kun je de lijst hardcoden, maar dat maakt het minder flexibel om de lijst uit te breiden naar die 58 Facebook-genders. Plus die 59e van Ben.
Een derde minpunt dat ik zo kan bedenken, is dat je een enum niet kan hergebruiken. Nu heb je een tabel met personen waarvan je het geslacht wilt opslaan, maar stel dat je er een tabel met huisdieren bijbedenkt, dan zul je die een eigen enum moeten geven. Als de geslachten in een tabel staan, kun je eenvoudig naar die tabel verwijzen vanuit je huisdier-record, maar bij een enum gaat dat niet.
Verder is het bij een enum mogelijk om een niet-genoemde waarde in je record te gebruiken. Die wordt dan door MySQL afgekapt tot een lege string. Is waarschijnlijk niet wat je wilt.
In jouw voorbeeld 2 kun je meerdere genders aan een user 'hangen'.
Kwestie van een unique constraint op user_id zetten. Of, beter, die hele koppeltabel overboord gooien en gaan werken met foreign keys. Dus:
- users -
. id
. name
. gender_id
. password
- gender -
. id
. name
waarbij gender_id een foreign key is van gender.id.
Een andere discussie: voor who de f**k heb je een veld gender nodig?
Zelfs als je een gebruiker een bericht wilt sturen is het anno 2016 prima om gewoon te beginnen met "Beste <voornaam>,". Dat is gewoon lekker vlot en zonder gezever, en niemand wil tegenwoordig nog een formulier invullen van meer dan vijf invulvelden.
Het moraal van mijn betoog: Denk goed over welke velden je wel of niet moet toevoegen aan je formulier.
Bonus: Laat gebruikers lekker inloggen met hun mailadres ipv zo een stomme unieke gebruikersnaam.
Frank, het ligt eraan wat voor site het is. En wat is nou de moeite om een M of V aan te klikken?
Klopt hoor Ariën. Het is slechts bedoeld om ts of lezers aan het denken te zetten. En een moeite is het voor sommige mensen wel. Bovendien vergeten mensen het ook gewoon en dan komt er een M te staan terwijl het een F moet zijn. Of er komt een foutmelding. Moet de gebruiker weer op zijn mobiel scrollen. En elke actie is een kans dat een gebruiker afhaakt.
Maar je hebt gelijk als je zegt dat het aan het type site ligt.
