[DB] Verschillende gegevens per gebruikersgroep

[Rhapsody]

Goedemorgen!!

Ik ben tegen een vraagstuk aangelopen waar ik zelf niet goed het antwoord op weet.

De situatie is alsvolgt:
Er zijn 4 soorten gebruikers: A, B, C en D.

Voor elke groep gebruikers wil ik een aantal gegevens opslaan. Een aantal gegevens gelden voor elke gebruikersgroep. Echter heb ik ook gegevens die op een enkele groep van toepassing zijn.

Mijn vraag is nu; hoe kan ik dit het beste oplossen in de database. Ik gebruik ASP.NET 2.0 en SQL Server. Standaard gebruik ik de aspnet_Users table voor de authenticatie en role-based-security.
Nu zijn er dus een aantla mogelijkheden:

• Voor elke gebruikersgroep een aparte tabel maken en die linken aan de aspnet_Users tabel.
• Een tabel maken met alle velden waarbij dan enkele velden leeg blijven.
• Een tabel voor de gegevens die voor iedere groep van toepassing zijn, en aparte tabellen voor de groep-specifieke gegevens.

Wellicht zal ik nog wat over het hoofd hebben gezien, maar wat lijkt jullie nu de beste oplossing?

[MaNdM]

Het is natuurlijk lastig te zeggen wat verstandig is als we niks weten van het datamodel en wat precies je bedoeling is met de gegevens.

Waar ik het eerst aan moest denken was dat je ook nog kan overwegen om een kolom aan de data toe te voegen waar een verzameling van usertypes in staat die recht hebben om deze data te zien. Bijvoorbeeld: A,C,D. Doormiddel van zowel ASP als SQL kan je controleren of een user rechten heeft om die data te bekijken.

[Rhapsody]

Het gaat nu enkel om de opslag. Dus niet om de weergave.

Dat is waar ik nu tegen aanloop. Hoe kan ik dit het beste opslaan.

Ik heb ze de eerste twee even uitgewerkt ter verduidelijking:


Optie 1

Optie 2

[MaNdM]

De eerste vraag die bij mij naar boven komt: Hoe groot is de kans dat er nog gebruikerssoorten bij zullen komen?

Als dit flexibel moet blijven dan zal je namelijk je datamodel ook flexibel moeten houden, ergo: geen tabellen maken die specifiek zijn voor een groep. Anders moet je voor iedere groep die toegevoegd wordt straks weer je datamodel gaan aanvullen, dat wil je niet.

Verder zie ik in je voorbeelden eigenlijk maar twee gebruikersgroepen, wat zijn de kenmerken van de overige groepen?

Ik ga er voor het gemak even vanuit dat het aantal groepen niet zal wijzigen en dan lijkt het mij het makkelijkst om te kiezen voor optie 1 met een extra kolom in aspnet_Users, namelijk UserType. Dan kan je op basis van die waarde laten bepalen waar de overige gegevens vandaan gehaald moeten worden.

[Rhapsody]

De definitieve gegevens heb ik nog niet. De liggen nog ter goedkeuring bij de opdrachtgever.

In principe is het aantal soorten gebruikers vast en zal dit niet uitgebreid hoeven worden.
Mijn voorkeur gaat eigenlijk ook uit naar de eerste oplossing. Mede omdat het niet uitgebreid hoeft te worden.

[Janoz]

Nadeel van de tweede optie is dat je geen ristricties meer op kunt leggen. Je kunt niet meer aangeven dat een Studentnummer verplicht en uniek is. Een Teacher heeft deze immers niet en alle teachers hebben dezelfde null value. Waar je nu tegenaan loopt is dat je probeert een object georienteerde structuur (met overerving) te mappen in een relationele structuur. In principe is over dit onderwerp een heleboel te vinden wanneer je op O/R mapping zoekt (let op het streepje, anders heb je behoorlijk last van het ruiswoord or )

Wanneer je voor optie 1 gaat kiezen kun je sowieso middels een union wel een view maken waarmee je de 2e oplossing simuleert. Ik zou sowieso geen veld UserType opnemen in je hoofd tabel. Wat voor type een gebruiker is is simpel te herleiden uit het aanwezig zijn van een record in 1 van de sub tabellen.

[Gé Brander]

@Rhapsody
Toch moet je daarmee oppassen. Nu is het duidelijk dat er niet uitgebreid gaat worden, maar wellicht in de toekomst is er een ander inzicht, en is toch de andere optie beter. Dan kan je beter meteen voor die optie gaan en voorbereid zijn, nietwaar?

[ Voor 3% gewijzigd door Gé Brander op 18-04-2006 11:42 ]

[Rhapsody]

c70070540 schreef op dinsdag 18 april 2006 @ 11:41:
@Rhapsody
Toch moet je daarmee oppassen. Nu is het duidelijk dat er niet uitgebreid gaat worden, maar wellicht in de toekomst is er een ander inzicht, en is toch de andere optie beter. Dan kan je beter meteen voor die optie gaan en voorbereid zijn, nietwaar?

Ja daar heb je gelijk in, dat is ook een beetje de twijfel die ik heb op dit moment.

@Janoz: ik ga even kijken naar O/R mapping Had er al wel een en ander over gelezen.

[ Voor 10% gewijzigd door Rhapsody op 18-04-2006 11:47 ]

[MaNdM]

Klopt, dat is te herleiden maar door een usertype op te nemen in de hoofdtabel hoef je minder ingewikkeld te doen. Gezien het feit dat het met ASP.NET moet gaan werken gok ik dat het voor een site is waar ook sessies gebruikt worden en dan is het makkelijker om de queries lekker simpel te houden en bij het inloggen meteen de usertype in de sessie op te nemen. Door te gaan herleiden in subtabellen ben je gedwongen om extra queries uit te voeren. Het is een kwestie van voorkeur denk ik.

c70070540 schreef op dinsdag 18 april 2006 @ 11:41:
@Rhapsody
Toch moet je daarmee oppassen. Nu is het duidelijk dat er niet uitgebreid gaat worden, maar wellicht in de toekomst is er een ander inzicht, en is toch de andere optie beter. Dan kan je beter meteen voor die optie gaan en voorbereid zijn, nietwaar?

Helemaal mee eens! In mijn ervaring is het nog altijd dat opdrachtgevers niet altijd ver genoeg vooruit denken. Dus bescherm jezelf en maak het flexibel.

[ Voor 35% gewijzigd door MaNdM op 18-04-2006 11:48 ]

[Rhapsody]

Gezien het feit dat ik de standaard tabellen van ASP.NET 2.0 gebruik hoef ik een aantal dingen niet op te nemen in mijn eigen tabellen. 1 van die dingen is het type gebruiker. Daar gebruik ik de RoleName voor.

Het liefst wil ik het toch flexibel en uitbreidbaar maken. Optie 1 heeft dat niet en is dus een groot nadeel. [ben even luid aan het nadenken]

Qua O/R mapping kom ik niet echt verder op het gebied van opslag.
Op internet kan ik ook nergens dezelfde vraagstelling vinden; me dunkt dat ik niet de eerste ben die hier tegenaan is gelopen??

[ Voor 23% gewijzigd door Rhapsody op 18-04-2006 12:52 ]