Wanneer 1 of meerdere tabels gebruiken?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

G P

G P

17/11/2016 17:00:46
Quote Anchor link
Wat is het best?

*** 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?
 
PHP hulp

PHP hulp

11/05/2021 14:55:58
 
Ramon van Dongen

Ramon van Dongen

17/11/2016 19:10:08
Quote Anchor link
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.
 
G P

G P

17/11/2016 19:11:38
Quote Anchor link
Dank je !
1 duidelijk antwoord :)
 
- Ariën -
Beheerder

- Ariën -

17/11/2016 21:50:07
Quote Anchor link
Als je echt safe wilt spelen maak je ook een 'beide' veld aan. Ideaal voor mannelijke of vrouwelijke transgenders.
Gewijzigd op 17/11/2016 21:51:20 door - Ariën -
 
Ben van Velzen

Ben van Velzen

17/11/2016 21:51:55
Quote Anchor link
<sarcasme>
Vergeet apache attack helicopter ook niet te vermelden als geslacht.
</sarcasme>
 
Ivo P

Ivo P

18/11/2016 10:02:46
Quote Anchor link
Facebook heeft een lijst van 58 mogelijke geslachten. Apaches staan daar nog niet bij, maar dan kom je op 59 :-)

http://abcnews.go.com/blogs/headlines/2014/02/heres-a-list-of-58-gender-options-for-facebook-users
 
Sander van t Hullenaar

Sander van t Hullenaar

18/11/2016 10:32:58
Quote Anchor link
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.
 
Willem vp

Willem vp

20/11/2016 13:18:51
Quote Anchor link
Ramon van Dongen op 17/11/2016 19:10:08:
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
 
Frank Nietbelangrijk

Frank Nietbelangrijk

20/11/2016 14:39:38
Quote Anchor link
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.
 
- Ariën -
Beheerder

- Ariën -

20/11/2016 14:48:37
Quote Anchor link
Frank, het ligt eraan wat voor site het is. En wat is nou de moeite om een M of V aan te klikken?
 
Frank Nietbelangrijk

Frank Nietbelangrijk

20/11/2016 16:10:47
Quote Anchor link
- 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
 
Ramon van Dongen

Ramon van Dongen

21/11/2016 11:59:40
Quote Anchor link
Offtopic:
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.
 
- Ariën -
Beheerder

- Ariën -

21/11/2016 12:23:52
Quote Anchor link
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.
Gewijzigd op 21/11/2016 12:24:36 door - Ariën -
 
Ward van der Put
Moderator

Ward van der Put

21/11/2016 13:42:03
Quote Anchor link
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.
 
Thomas van den Heuvel

Thomas van den Heuvel

21/11/2016 14:04:10
Quote Anchor link
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?
 
Ward van der Put
Moderator

Ward van der Put

21/11/2016 14:45:16
Quote Anchor link
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?

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.