Wanneer 1 of meerdere tabels gebruiken?
*** Voorbeeld 1 ***
- users -
. id (int)
. name (varchar)
. password (varchar)
. gender (enum('m','f'))
of?
*** Voorbeeld 2 ***
- users -
. id
. name
. password
- gender -
. id
. name
- users_gender -
. user_id
. gender_id
Wanneer gebruik je 1 of meerdere tabellen?
Quote:
Wanneer gebruik je 1 of meerdere tabellen?
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.
1 duidelijk antwoord :)
Gewijzigd op 17/11/2016 21:51:20 door - Ariën -
Vergeet apache attack helicopter ook niet te vermelden als geslacht.
</sarcasme>
http://abcnews.go.com/blogs/headlines/2014/02/heres-a-list-of-58-gender-options-for-facebook-users
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.
Ramon van Dongen op 17/11/2016 19:10:08:
Meerdere wanneer dat noodzakelijk is ivm je database normalisatie.
Quote:
Wanneer gebruik je 1 of meerdere tabellen?
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.
Quote:
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.
Gewijzigd op 20/11/2016 13:20:58 door Willem vp
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.
- Ariën - op 20/11/2016 14:48:37:
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.
Gewijzigd op 20/11/2016 16:11:33 door Frank Nietbelangrijk
Quote:
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.
De meeste mensen hebben wel een smartphone, met daarop een eigen mailadres. Bij Android is het zelfs standaard.
Gewijzigd op 21/11/2016 12:24:36 door - Ariën -
Willem vp op 20/11/2016 13:18:51:
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.
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?
Thomas van den Heuvel op 21/11/2016 14:04:10:
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?
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.