Waar kolom plaatsen bij een M:N relatie (RDB design)

[S.O.]

Hoi iedereen,

Ik ben (nog steeds) bezig om een ERD diagram te maken voor een database voor een toekomstige evenementen website.

Op dit moment ben ik aan het zoeken wat de juiste locatie is voor bepaalde kolommen.
In welk tabel kan ik deze het beste plaatsen?


Situatie:
Tabel user met gegevens van een gebruiker.
Tabel account met gegevens van een account.
Tabel event met gegevens van evenementen.

Om ervoor te zorgen dat een account meerdere users kan hebben en users bij meerdere accounts kunnen, maak je gebuik van een koppel tabel (jt_membership) (M:N relatie)
Maar ik wil wel er wel voor zorgen dat een account maar 1 eigenaar heeft.
Deze bepaald welke users allemaal toegang krijgen tot het account.
Dit moet dus ergens geborgd worden.
Wat is de beste locatie hiervoor?
Zet ik deze het beste ook in het koppeltabel als extra kolom of in het account tabel als extra kolom?
Zeker als je er ook rekening mee wil houden dat er een mogelijkheid moet zijn om het eigenaarschap over te dragen aan een andere user.


Hetzelfde geld voor een evenement.
Aan een evenement kunnen meerdere accounts gekoppeld worden, wanneer dit een samenwerkings verband is.
Hiervoor gebruik ik jt_organiser tabel.
Aangezien je toch wil dat er iemand de eigenaar is van het evenement, moet ook dit ergens vermeld worden.
Tevens wil je de mogelijkheid hebben om het eigenaarschap te kunnen overdragen van het evenement.
Zet je deze kolom in de jt_organizer tabel of in het event tabel.

user <> jt_memebership <> account <> jt_organiser <> event

Zelf zat ik te denken of ze in de tabel account & event te plaatsen aangezien dit eigenlijk een 1:1 relatie is.

Zit ik op de goede weg of zie ik (nog) dingen over het hoofd i.v.m. het maken van Queries of optimalizatie issue's waar ik nu (nog) geen kennis van heb.

Groet S.O.

[CurlyMo]

S.O. schreef op zondag 17 februari 2019 @ 17:48:
Maar ik wil wel er wel voor zorgen dat een account maar 1 eigenaar heeft.
Deze bepaald welke users allemaal toegang krijgen tot het account.
Dit moet dus ergens geborgd worden.
Wat is de beste locatie hiervoor?

Wat je zelf al voorstelt kan allemaal.

Als dit categorisch zo blijft dan is het het simpelst om gewoon een kolom aan je account tabel toe te voegen met een relatie naar je user tabel die je bijv. admin_id noemt. Deze gebruiker is dan admin voor dat account.

Enige nadeel is dus wel dat je nooit meerdere admins kan hebben en je het updaten van je admin goed in een transactie moet zetten zodat je zeker weet dat een account niet zonder admin komt te zitten.

Een aanvullende kolom aan je koppeltabel kan ook. Simpelste vorm daarvan is gewoon een boolean met bijv. is_admin. Enige nadeel is dat je wel middels een check constraint moet zorgen dat deze waarde maar één keer waar kan zijn per account.

Dezelfde logica gaat ook op voor je evenementen vraag.

[Kalentum]

S.O. schreef op zondag 17 februari 2019 @ 17:48:
Wat is de beste locatie hiervoor?
Zet ik deze het beste ook in het koppeltabel als extra kolom of in het account tabel als extra kolom?
Zeker als je er ook rekening mee wil houden dat er een mogelijkheid moet zijn om het eigenaarschap over te dragen aan een andere user.

Als een account maar 1 owner kan hebben dan zou ik het in de accounts tabel zetten. Met als bijkomend voordeel dat je per definitie maar 1 owner per account kan hebben.
Als je de mogelijkheid wil hebben om een account meerdere owners te laten hebben, dan in de koppeltabel.

Zelf zat ik te denken of ze in de tabel account & event te plaatsen aangezien dit eigenlijk een 1:1 relatie is.

Ja precies. Tenzij je dus meerdere owners per account of event wil kunnen hebben

CurlyMo schreef op zondag 17 februari 2019 @ 17:58:
[...]
... je het updaten van je admin goed in een transactie moet zetten zodat je zeker weet dat een account niet zonder admin komt te zitten.

Waarom een transactie? Het is 1 update statement.

[ Voor 15% gewijzigd door Kalentum op 17-02-2019 18:02 ]

[CurlyMo]

rutgerw schreef op zondag 17 februari 2019 @ 18:00:
[...]
Waarom een transactie? Het is 1 update statement.

je hebt gelijk.

In zat met mijn gedachte al bij het tweede deel van mijn antwoord

[ Voor 22% gewijzigd door CurlyMo op 17-02-2019 18:04 ]

[S.O.]

Dus eigenlijk moet ik mezelf de volgende vragen stellen:

Wil ik in de toekomst meerdere eigenaren aan een evenement koppelen of niet.
Zo ja >> in koppel tabel >> is de jt_organiser tabel de juiste of nieuw koppeltabel
Zo niet >> in event tabel

Wil ik in de toekomst meerdere eigenaren hebben voor een account.
Zo ja >> in koppel tabel >> is de jt_membership tabel de juiste of nieuwe koppel tabel
Zo niet >> in account tabel

Hier eens over nadenken..

Zijn er nadelen om de optie voor meerdere eigenaren beschikbaar te maken in de database maar bijv. nog niet beschikbaar te maken in de web applicatie?

Grt. S.O.

[ Voor 10% gewijzigd door S.O. op 17-02-2019 18:16 ]

[CurlyMo]

S.O. schreef op zondag 17 februari 2019 @ 18:12:
Zijn er nadelen om de optie voor meerdere eigenaren beschikbaar te maken in de database maar bijv. nog niet beschikbaar te maken in de web applicatie?

Nee, maar als je naar meer flexibiliteit neigt, dan moet je je afvragen of dit wel de juiste implementatie is. Want je rechten structuur beperkt zich dan louter tot één of meer admins. Dat is voor een rechtenstructuur vrij beperkt.

En afhankelijk van hoe belangrijk je het vind moet je zorgen dat het bijwerken van de admin status in het tweede geval wel de juiste uitkomst krijgt en je niet opeens met twee of meer of geen admin zit. Dus transacties en check constraints.

[S.O.]

CurlyMo schreef op zondag 17 februari 2019 @ 18:16:
[...]

Nee, maar als je naar meer flexibiliteit neigt, dan moet je je afvragen of dit wel de juiste implementatie is. Want je rechten structuur beperkt zich dan louter tot één of meer admins. Dat is voor een rechtenstructuur vrij beperkt.

En afhankelijk van hoe belangrijk je het vind moet je zorgen dat het bijwerken van de admin status in het tweede geval wel de juiste uitkomst krijgt en je niet opeens met twee of meer of geen admin zit. Dus transacties en check constraints.

Dus dat is eigenlijk een eenvoudige beslissing m.b.t. database design >> Mogelijkheid beschikbaar maken.

Nu nog uitzoeken of dat dan aparte koppel tabellen moeten worden of dat ik ze bij de bestaande kan toevoegen.

[CurlyMo]

S.O. schreef op zondag 17 februari 2019 @ 18:21:
[...]


Dus dat is eigenlijk een eenvoudige beslissing m.b.t. database design >> Mogelijkheid beschikbaar maken.

Nu nog uitzoeken of dat dan aparte koppel tabellen moeten worden of dat ik ze bij de bestaande kan toevoegen.

Het ideale database ontwerp heeft antwoord op alle mogelijke vragen, ook degene die nog niet gesteld zijn, en is performant. Een goed database ontwerp past bij de functionele eisen die er gesteld zijn. Als je functionele eis voor nu en de nabije toekomst is om één of meer admins te hebben, dan zou ik dat gewoon zo implementeren zoals je al had bedacht. Als je eis wordt om een meer complex rechtensysteem te implementeren, dan kan je daar eventueel vast over nadenken. Enige risico dat je loopt is dat je te lang in het ontwerpfase blijft hangen

De één admin implementatie ombouwen tot een toekomstig volledig rechtensysteem lijkt me alleen iets makkelijker dan de meerdere admins implementatie ombouwen. Dat kan je ook nog meewegen in je overwegingen.