Ik ben bezig met een project waarin je als gebruiker een relatie kunt leggen met en andere gebruiker. In eerste instantie heet deze relatie "nieuw" en kan vervolgens over gaan in "geaccepteerd", "tijdelijk niet" of "afgewezen". Ik dacht de relatie op te slaan in een volgende tabel:
CREATE TABLE IF NOT EXISTS `gebruikers` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`naam` varchar(50) NOT NULL,
PRIMARY KEY (`id`)
) ;
CREATE TABLE IF NOT EXISTS `relaties` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`gebruiker1` int(11) NOT NULL,
`gebruiker2` int(11) NOT NULL,
`relatie` int(11) NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE IF NOT EXISTS `relatietypes` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`relatietype` varchar(50) NOT NULL,
PRIMARY KEY (`id`)
) ;
Opvraag query
SELECT
*
FROM
gebruikers g1
left JOIN
relaties r
on g1.id=r.gebruiker1
left JOIN
relatietypes rt
on rt.id=r.relatie
LEFT JOIN
gebruikers g2
on g2.id=r.gebruiker2
Elke gebruiker kan 1 of meerdere linken hebben met 0 of meerdere gebruikers. Je moet zelf controleren of alles kan en mag.
Je kan ook een link/status hebben met jezelf :)
Jan
?Onbekende gebruiker
01-06-2022 09:34
gewijzigd op 01-06-2022 09:40
De opzet met een tussentabel is correct, hiermee maak je een m:m-relatie. In die tabel heb je inderdaad een kolom per gebruiker, en als je wilt voorkomen dat een gebruiker een relatie met zichzelf heeft maak je een check constraint dat beide ID's niet gelijk mogen zijn aan elkaar.
Dan nog een kolom voor voor de status. Wat je niet moet doen is daar een enum-veld van maken. Het beste is inderdaad om daar een id met een FK naar een aparte statustabel van te maken, dan is het bestendig voor toekomstige wijzigingen.
Nu kun je van die drie kolommen een PK maken. Daar heb je genoeg aan. Je kunt er ook voor kiezen om een aparte ID kolom aan te maken. Die heeft geen praktisch nut, anders dat je in queries iets makkelijker naar de rij kan wijzen. Vergeet dan niet om nog steeds een unique constraint te maken voor de gebruikers en de status.
Wil je ook historie bijhouden, dan wordt een ID-kolom met een sequence al handiger. Je hebt daarbij nog een tijdstempel-kolom nodig met het moment van de statuswijziging. De unique constraint moet komen te vervallen.
Voor de prestaties is het aan te raden om op de kolommen van gebruikers en datum een index aan te maken, zodat de database queries voor het opvragen van de status extra snel kan uitvoeren.
Laatste tip: gebruik zinvolle naamgeving voor de kolommen. Geen gebruiker1 en gebruiker2, maar bijvoorbeeld id, gebruiker_van, gebruiker_naar, status en moment.
