Bonus: Laat gebruikers lekker inloggen met hun mailadres ipv zo een stomme unieke gebruikersnaam.
Werkt ook niet altijd en hangt weer af van de site en wat voor gebruikers. Laatst voor een harmonie vereniging met dus ook wat oudere leden. Man en vrouw zijn beide lid en hebben 1 gezamenlijk e-mailadres. Ze moeten wel onafhankelijk van elkaar in kunnen loggen.
Het e-mailadres als gebruikersnaam werkt dan dus niet helaas.
Dat is inderdaad een scenario die meespeelt. Maar bij webwinkels en diverse sites ontkom je er niet aan. Er wordt tegenwoordig verwacht dat ieder een eigen mailadres heeft. Een Outlook, Hotmail, Livemail, Gmail is bovendien zo aangemaakt.
De meeste mensen hebben wel een smartphone, met daarop een eigen mailadres. Bij Android is het zelfs standaard.
Grappig dat je het woord 'normalisatie' noemt. In voorbeeld 1 wordt namelijk een enum gebruikt, en als er iets is dat zo ongeveer 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.
Het hangt er maar van af... Als je namelijk ISO/IEC 5218 volgt, heb je voldoende aan vier kleine integers voor het geslacht. Moet je die vier TINYINT's dan nog aan een tweede tabel zetten? Een ENUM doet onder water namelijk vrijwel precies hetzelfde.
Het voordeel van een aparte tabel met een verwijzing middels een foreign key is tevens dat alles geïndexeerd is.
Hoe efficiënt kun je selecties maken op ENUM-velden?
Wat me bij het volgende punt brengt: misschien is het beter om de opzet van de tabelstructuur (mede / sterk) af te laten hangen van hoe je deze gebruikt / hoe je hier in zoekt? Dat bepaalt toch in wezen welke opzet "efficiënt" is?
Het voordeel van een aparte tabel met een verwijzing middels een foreign key is tevens dat alles geïndexeerd is.
Hoe efficiënt kun je selecties maken op ENUM-velden?
Dan zou je zelf een index op de kolom kunnen zetten, maar kom je er hopelijk binnen afzienbare tijd achter dat die bij een TINYINT(1) of BIT(1) met slechts twee mogelijke waarden niets toevoegt.
Als ik kolom voor een flag of switch gebruik, voeg ik ook geen aparte tabel toe om te declareren dat 0 false/no/off betekent en 1 true/yes/on. Pas je op een vergelijkbare wijze een internationale ISO-standaard toe, dan kun je je afvragen of het nog wel zinvol is om in je database met een aparte tabel te formaliseren dat 1 man en 2 vrouw betekent.
