[Conceptueel] Database many-to-many met meta data in ORM

[Carharttguy]

Dag mede-Tweakers

Ik probeer wat bij te leren en te programmeren. Ik werk in een wat onbenullige taal B4X omdat ik dat leuk vind.
Nu werk ik vaak met een MySQL database en daaruit vloeit voort dat ik vaak modellen maak die de verschillende tables weerspiegelen. Maar omdat dit nogal repetitief werk is en ik weet dat er in andere talen vaak gebruik wordt gemaakt van ORM en ik in een avontuurlijke bui ben dacht ik: Waarom niet m'n eigen ORM(tje) maken. For the sake of it. Het idee is dat ik eerst een MySQL database maak, en vanaf daar makkelijk mijn klasses kan genereren die corresponderen met tables. Ik heb zelf nog nooit een ORM pakket gebruikt.

Zo gezegd, zo gedaan. Maar ik zit in de problemen met many-to-many relaties + meta data.

Voorbeeld:


Dus je ziet een User, die heeft 1 of meerdere wallets. En een wallet heeft 1 of meerdere 'eigenaars'.

Mijn probleem zit in deze op de meta data 'permission'. Permission kan in dit geval bijvoorbeeld 0, 1, 2 zijn. Waar 0 enkel het bekijken van de wallet is, 1 dat er ook geld kan uitgegeven worden, en 2 dat je je owner rights hebt en dus anderen rechten kan geven. Dit is een beetje een gemaakt voorbeeld, en ik snap dat er andere manieren zijn om rechten te regelen, maar het is gewoon een voorbeeld ter illustratie van mijn probleem.

De models die ik genereer zijn dus 2 classes:
User en Wallet. Een User heeft een property Wallets dat een List van Wallet objecten terug geeft. Omgekeerd heeft een Wallet een property Users dat een List van User objecten terug geeft.

Maar hoe zou ik de rechten hierin verwerken? Ik wil vermijden dat ik aparte User_Wallet klasse moet maken, omdat dit OOP gewijs wat wringt en teveel naar MySQL neigt.

De artikels die ik online vind over ORM's zoals Doctrine of Django etc gaan niet in op metadata over de many-to-many relatie.

Meningen, tips of ideeën zijn erg welkom!

[mulder]

Het is imho geen meta data. Ik zie meer een tabel met UserPermission oid, waar userid + recht + resource staat.

Edit: Ik lees verkeerd...

[ Voor 11% gewijzigd door mulder op 10-10-2019 19:53 . Reden: Sorry ik moet idd niet 2 dingen tegelijk doen ]

[Carharttguy]

Maar dat is toch exact wat ik hier heb?
UserID
WalletID (resource)
en recht?

Maar die "meta dataé zoals ik het noem kon ook iets anders zijn, het was maar een voorbeeld. Bvb link_created wat een datetime is of zo.

[Wmm]

Carharttguy schreef op donderdag 10 oktober 2019 @ 15:56:
Maar hoe zou ik de rechten hierin verwerken? Ik wil vermijden dat ik aparte User_Wallet klasse moet maken, omdat dit OOP gewijs wat wringt en teveel naar MySQL neigt.

Hoe bedoel je deze twee punten precies?

Je ontkomt volgens mij niet aan een class UserWallet oid, en volgens mij is dat OOP gezien ook prima. Het model is namelijk geen simpele many-to-many meer, wat enkel een join table is. In plaats daarvan wordt het 2x een one-to-many naar de UserWallet class die logica omtrent de permissions bevat (de permissions vind ik dus ook geen meta data). Mogelijk zou een betere naam voor de UserWallet class alles al een stuk logischer maken, ik zou er zo alleen geen weten.

Het is dat, of je zult de permissions op een hele andere manier moeten regelen. Dat zou b.v. kunnen als de permissions altijd gelijk zijn voor alle wallets van één bepaalde user (maar ik ga er maar vanuit dat dat niet zo is), dan kun je wel ontkomen aan een UserWallet class.

[Mugwump]

Carharttguy schreef op donderdag 10 oktober 2019 @ 19:45:
Maar dat is toch exact wat ik hier heb?
UserID
WalletID (resource)
en recht?

Maar die "meta dataé zoals ik het noem kon ook iets anders zijn, het was maar een voorbeeld. Bvb link_created wat een datetime is of zo.

Een 'many-to-many' relatie in een ORM is doorgaans echt enkel bedoeld voor relaties zonder extra data. Als je vanuit SQL perspectief een koppeltabel met extra (meta)data wil, dan moet je die gewoon als extra entiteit modelleren met one-to-many relaties van de andere twee entiteiten naar de entiteit voor de 'koppeltabel'. Zie hier of hier voor een voorbeeld van hoe dat b.v. met JPA / Hibernate kan.

[EfBe]

(Ik werk aan ORMs voor mn werk)

Een m:n relatie is doorgaans een read-only relatie over 2 m:1 relaties. Dus A 1:n B m:1 C -> A m:n C. Dit is een 'objectified' relationship zoals Halpin dat noemt wanneer er non-pk attributes (velden) in B zitten. Jouw voorbeeld is er een en dat levert dan User m:n Wallet op. Dit is een readonly relationship omdat het in feit een view is op de 2 onderliggende relationships. Wil je dus entities saven met die relationship dan zul je die moeten saven via de onderliggende m:1 relationships.

De andere variant voor m:n is dat je direct A m:n C definieert en er geen feitelijke entity B is, want er zijn geen non-pk attributes die B vormen. Dit levert een 'hidden' B op met louter PK fields die ook FK zijn. Dat neemt niet weg dat B niet bestaat, wat sommige ORMs doen, die maken B hidden en je kunt dan bv een C aan een A instance assignen en die hierarchie saven en de B instance wordt dan door de ORM verzorgd.

Ik ben daar niet zo'n fan van, temeer omdat in veel gevallen toch non-pk attributes worden gedefinieerd voor wat dan 'B' gaat heten en je hebt ineens een non-hidden entity B wat je code drastisch kan beinvloeden. Wanneer je vanaf het begin B als non-hidden had beschouwd was dat niet nodig geweest.

[ Voor 13% gewijzigd door EfBe op 12-10-2019 11:06 ]