Ik zat me ineens iets af te vragen. Als je gebruikers/users hebt, dan kun je "simpele" users hebben, en "uitgebreide" users.
Wat ik bedoel is dit. Stel iemand meldt zich via je website aan voor een nieuwsbrief. Het enige dat die persoon invult is zijn naam en e-mailadres. We kunnen dus zeggen dat het om een "simpele" user gaat, waarvan we alleen de naam en het e-mailadres weten. We kunnen ook "uitgebreide" users hebben. Stel je voor, iemand koopt een product via een webshop, dan weten we niet alleen zijn/haar naam en e-mailadres, maar ook woonplaats en adres. En in weer andere situaties weet je misschien ook wel de geboortedatum.
Nu vraag ik me af. Stel dat je een abstracte user class zou maken, waarop alle andere users zijn gebaseerd. Moet je die class dan zo "simpel" mogelijk houden (dus alleen een naam en e-mailadres), of moet je die juist zo "uitgebreid" mogelijk maken, en null returnen indien bepaalde gegevens niet bekend zijn?
>> Zou je kunnen uitleggen waarom één tabel is gelijk aan één klasse, geen goede implementatie zou zijn? De hele ORM principe draait hier eigenlijk om.
Als één gebruiker meerdere e-mailadressen heeft, zijn dat in een goed genormaliseerde database twee tabellen. Toch kun je dan één User-class hebben.
Voor veel-op-veel-relaties wordt de complicatie nog groter. Eén gebruiker kan meerdere adressen hebben. Maar één adres kan omgekeerd ook door meerdere gebruikers worden gebruikt. In een database is dat geen punt: je gebruikt gewoon drie tabellen. In een webapplicatie modelleer je dat echter niet vanzelfsprekend met drie classes. Het kunnen er ook meer of minder zijn.
>> Zou je kunnen uitleggen waarom één tabel is gelijk aan één klasse, geen goede implementatie zou zijn? De hele ORM principe draait hier eigenlijk om.
Als één gebruiker meerdere e-mailadressen heeft, zijn dat in een goed genormaliseerde database twee tabellen. Toch kun je dan één User-class hebben.
Voor veel-op-veel-relaties wordt de complicatie nog groter. Eén gebruiker kan meerdere adressen hebben. Maar één adres kan omgekeerd ook door meerdere gebruikers worden gebruikt. In een database is dat geen punt: je gebruikt gewoon drie tabellen. In een webapplicatie modelleer je dat echter niet vanzelfsprekend met drie classes. Het kunnen er ook meer of minder zijn.
Eens, ik had het scenario van een veel-op-veel relatie niet meegenomen. Verder delen we wel gewoon dezelfde mening en daar was ik benieuwd naar.
Als 1 User meerdere emailadressen heeft dan heeft de User object een n-n relatie met het Email object.
Dennis, merk op dat je jouw denkwijze van een ORM iets moet aanpassen. Het gaat in een ORM namelijk niet om je tabel, maar om je object. Code-first zeg maar. Dus elk object heeft zijn eigen tabel, maar niet perse elke tabel hoeft een object te hebben.
Als 1 User meerdere emailadressen heeft dan heeft de User object een n-n relatie met het Email object.
Dennis, merk op dat je jouw denkwijze van een ORM iets moet aanpassen. Het gaat in een ORM namelijk niet om je tabel, maar om je object. Code-first zeg maar. Dus elk object heeft zijn eigen tabel, maar niet perse elke tabel hoeft een object te hebben.
Bedoel je niet een 1:n relatie? n:n houd in dat hetzelfde een mailadres aan meerdere gebruiker gekoppeld kan zijn, minder gebruikelijk lijkt mij.
Ik deel jou beeld van een ORM implementatie, je hebt gelijk dat mijn uitleg het Code-first idee niet ondersteunde.
@Dennis Wat mij betreft, kun je gerust klassen hebben die "naast" tabellen staan. Dat hoeft niet per se een één-op-één-relatie te zijn tussen tabel en klasse.
Neem een concreet voorbeeld. Met een class NederlandsePostcode extends Postcode en een class BelgischePostcode extends Postcode heb ik drie klassen die drie typen postcodes kunnen afhandelen. Heb ik daarvoor dan drie databasetabellen nodig? Nee, niet per se. Moet ik postcodes dan opslaan in een aparte tabel? Nee, ook dat niet.
Jongens, de discussie dwaalt een beetje af. Ik ga mijn vraag nog een keer stellen en ben dan benieuwd naar jullie antwoord. We vergeten even het hele database gebeuren.
Stel we hebben een auto en een fiets. Beiden zijn voertuigen, dus het lijkt me dan zinvol om een abstracte class Voertuig te maken. Mee eens?
Nu is mijn vraag wat er in die abstracte class thuis hoort.
We kunnen stellen dat ieder voertuig kan sturen, remmen en gasgeven. Dus in de voertuig class kunnen we de methods stuurLinks, stuurRechts, rem en gas zetten. Maar... hoort daar bijv. ook een method getNummerbord in? Veel voertuigen hebben een nummerbord, maar een fiets bijvoorbeeld niet. Plaatsen we de getNummerbord method in de voertuig class en accepteren we dat het mogelijk is dat iemand van een fietsobject het nummerbord opvraagt? Of plaatsen we getNummerbord alleen in de auto class?
