MySQL tabellen aanmaken in PHPMyAdmin

[StijnFlorian]

Goedemorgen mede-tweakers,

Voor een schoolopdracht ben ik een helpdeskwebsite aan het opzetten in HTML, CSS en PHP. Nu kom ik bij het volgende "probleem" uit. Zowel customers als employees moeten kunnen inloggen en hebben verschillende rechten. Maar vanwege de check op al bestaande email bij registreren lijkt het mij verstandig om deze gegevens in een tabel te hebben. Maar hoe houdt ik dit onderscheid tussen de twee groepen?

Ik hoor graag jullie mening en tips!

Met vriendelijke groet,
StijnFlorian

[AW_Bos]

In het simpelste geval benoem je gewoon de 'role' van de gebruiker in de gebruikerstabel?
Dus [e-mail] = employee, en [e-mail] is customer.

Aan de hand van deze rol kan je de juiste rechten geven. Dus iemand die employee is, kan bijvoorbeeld /administration in.

[sam.vimes]

Bedenk dat je waarschijnlijk een een many-to-many relatie moet leggen tussen de tabel met gebruikers en de tabel met rollen, omdat elke rol aan meerdere gebruikers kan worden gegeven, maar ook gebruikers meerdere rollen kunnen hebben.

[0rbit]

sam.vimes schreef op donderdag 26 maart 2026 @ 13:59:
Bedenk dat je waarschijnlijk een een many-to-many relatie moet leggen tussen de tabel met gebruikers en de tabel met rollen, omdat elke rol aan meerdere gebruikers kan worden gegeven, maar ook gebruikers meerdere rollen kunnen hebben.

Dat is normaalgesproken zo, maar volgens mij is het voor deze opdracht voldoende twee specifieke groepen te definieren en iedere groep heeft een eigen rechtenstructuur. Je moet dan van iedere user bijhouden tot welke groep de user behoort.

Je zou in de tabel "users" een field "is_employee" ofzo kunnen maken. Baserend op de waarde van dit veld maak je dan dynamisch je website.

[eheijnen]

De documentatie:
https://dev.mysql.com/doc/mysql-security-excerpt/8.0/en/roles.html

[Patriot]

eheijnen schreef op donderdag 26 maart 2026 @ 14:28:
De documentatie:
https://dev.mysql.com/doc/mysql-security-excerpt/8.0/en/roles.html

Dat heeft echt helemaal niks te maken met het probleem van TS

[Knutselsmurf]

Waarschijnlijk heb je nu een tabel met customers en een tabel met employees, ieder met een eigen veld voor de username en een veld voor het (gehashte) wachtwoord. Dit betekent dan ook dat je bij inloggen in twee tabellen moet zoeken naar de ingelogde user.

Als je het inlog-gedeelte verplaats naar een nieuwe user-tabel, met daarin : username, wachtwoord, customer_id en employee_id, dan heb je alle inloggegevens in 1 tabel staan.

Dan kun je daar centraal afdwingen dat de email/username uniek is. Bij inloggen hoef je ook maar op 1 plek op zoek naar de user. Afhankelijk van de bijbehorende employee of customer_id (slechts één van de twee kan gevuld zijn) weet je of het om een customer of een employee gaat en kun je de gebruiker naar de bijbehorende pagina doorsturen.

Alle customer-specifieke gegevens houd je in de customer tabel, net als de employee-gegevens in de employee-tabel

[DUX]

0rbit schreef op donderdag 26 maart 2026 @ 14:07:
[...]


Dat is normaalgesproken zo, maar volgens mij is het voor deze opdracht voldoende twee specifieke groepen te definieren en iedere groep heeft een eigen rechtenstructuur. Je moet dan van iedere user bijhouden tot welke groep de user behoort.

Je zou in de tabel "users" een field "is_employee" ofzo kunnen maken. Baserend op de waarde van dit veld maak je dan dynamisch je website.

Dat klinkt inderdaad heel aannemelijk, en ook maakt dat het opvragen van gegevens uit de database een stuk eenvoudiger. Maar flexibel c.q. toekomstbestendig is het niet per se.

De TS moet even een inschatting gaan maken waarop beoordeeld gaat worden. Het generiek maken van rollen en het verder uitsplitsen van je ontwerp maakt aanpassingen later makkelijker, en dat zou een pluspunt in de eindpresentatie kunnen zijn. Het toevoegen van een extra rol gaat dan makkelijker, zoals bijvoorbeeld magazijnbeheerder of manager. Je hebt voor dit voorstel minstens de volgende tabellen:

• tabel met persoonsgegevens inclusief e-mailadres
• tabel met de namen en rechten van de verschillende rollen die je kent (gebruiker, beheerder, [toekomstige rol])
• Een koppeltabel waarmee je via de vreemde sleutels (foreign keys) personen aan rollen koppelt (dit maakt het ook mogelijk om meerdere rollen toe te kennen aan één account)

Dit zou je nog verder kunnen uitsplitsen ("normaliseren") maar bovenstaand zou genoeg kunnen zijn.

Verder moet je bedenken of werknemers misschien ook gewoon klant kunnen zijn en hoe je daarmee om wilt gaan: moeten zij twee verschillende accounts hebben of niet, en uitleggen in je eindpresentatie waarom wel of niet.

[0rbit]

Is het een opdrachtje van een week? Of is het een eindopdracht waar je een half jaar mee bezig gaat zijn? In het tweede geval, zou ik doen wat DUX hierboven schrijft :-)

[AW_Bos]

eheijnen schreef op donderdag 26 maart 2026 @ 14:28:
De documentatie:
https://dev.mysql.com/doc/mysql-security-excerpt/8.0/en/roles.html

Dat heeft te maken met de rollen en rechten van gebruikers in MySQL zelf. Hier in het topic gaat het om gebruikersrollen in een applicatie. Dus hier heeft de TS niks aan voor zijn vraagstuk.

Voor TS de @StijnFlorian ben ik benieuwd of er uitgebreide specificaties zijn voor de opzet van een rollen/rechten systeem. Je kan het zo uitgebreid maken zoals je maar wilt (bij interesse, verdiep je in een RBAC-structuur), maar als er weinig specificaties zijn, kan je het ook op simpele wijze bouwen met een paar velden en zonder relaties.

[ Voor 5% gewijzigd door AW_Bos op 27-03-2026 13:29 ]

[eheijnen]

@AW_Bos
Was uit de heup geschoten...
Anderzijds zit er ook wel weer overlap in.

[AW_Bos]

eheijnen schreef op vrijdag 27 maart 2026 @ 15:27:
@AW_Bos
Was uit de heup geschoten...
Anderzijds zit er ook wel weer overlap in.

Het heeft 0,0 betrekking op het probleem.

[Kheos]

eheijnen schreef op vrijdag 27 maart 2026 @ 15:27:
@AW_Bos
Was uit de heup geschoten...
Anderzijds zit er ook wel weer overlap in.

Overlap buiten het woord 'role'?

[eheijnen]

Komt op role based access neer in beide gevallen.
Hij heeft twee groepen/rollen en een lijst met users en in mysql bestaat er ook een "soortgelijk" systeem elementair gezien....

[frumper]

Knutselsmurf schreef op donderdag 26 maart 2026 @ 14:34:
Waarschijnlijk heb je nu een tabel met customers en een tabel met employees, ieder met een eigen veld voor de username en een veld voor het (gehashte) wachtwoord. Dit betekent dan ook dat je bij inloggen in twee tabellen moet zoeken naar de ingelogde user.

Als je het inlog-gedeelte verplaats naar een nieuwe user-tabel, met daarin : username, wachtwoord, customer_id en employee_id, dan heb je alle inloggegevens in 1 tabel staan.

Dan kun je daar centraal afdwingen dat de email/username uniek is. Bij inloggen hoef je ook maar op 1 plek op zoek naar de user. Afhankelijk van de bijbehorende employee of customer_id (slechts één van de twee kan gevuld zijn) weet je of het om een customer of een employee gaat en kun je de gebruiker naar de bijbehorende pagina doorsturen.

Alle customer-specifieke gegevens houd je in de customer tabel, net als de employee-gegevens in de employee-tabel

Of je past je front-end aan naar inloggen gebruiker / inloggen medewerker.

[AW_Bos]

eheijnen schreef op vrijdag 27 maart 2026 @ 16:13:
Komt op role based access neer in beide gevallen.
Hij heeft twee groepen/rollen en een lijst met users en in mysql bestaat er ook een "soortgelijk" systeem elementair gezien....

het enige hoe je het MySQL rechtensysteem kan toepassen in dit project, is een scheiding aanbrengen in de connectie tussen de frontend en backend. Bij de frontend wil je geen DELETE of TRUNCATE rechten uit kunnen voeren, en bij voorkeur markeer je iets als verwijderd als je iets wilt verwijderen.

En in de backend wilt je meer rechten hebben, zoals DELETE en TRUNCATE. Dus mocht iemand een security-lekje vinden in de frontend, kan je door je scheiding in de database-connectie en users toch een veiligheid creëren.

Maar dit staat (lijkt mij) los van de scope van dit schoolproject.

[Boudewijn]

eheijnen schreef op vrijdag 27 maart 2026 @ 16:13:
Komt op role based access neer in beide gevallen.
Hij heeft twee groepen/rollen en een lijst met users en in mysql bestaat er ook een "soortgelijk" systeem elementair gezien....

Je os heeft ook users en rollen. En daar houdt de vergelijking ook wel een beetje op denk ik.

De ts heeft het over gebruikers in een applicatie, jij over een database backend. Zijn rollen zijn er twee en zelfbouw, die van jou zijn compleet anders. Ik denk dat je toevoeging de ts niet verder helpt

[Woy]

Op zich is het prima om hier vragen over huiswerk te stellen, maar we verwachten sowieso meer input over wat je zelf al bedacht en geprobeerd hebt.