Database constructie discussie

[nemo55]

Momenteel op heb ik een discussie met een collega hoe we een database het beste kunnen wijzigen om een nieuwe functionaliteit toe te voegen.

Ik zou graag jullie mening willen horen over het volgende:

Op het moment is het zo ingericht dat een user gekoppeld is aan één onderneming. In een aparte tabel worden de rechten voor de user bijgehouden. Nu gaat een user aan meerdere ondernemingen gekoppeld worden waarvoor per onderneming de rechten ingesteld dienen te worden. Daarnaast moet in de applicatie aangegeven kunnen worden of het mogelijk is om voor een bepaalde user om bepaalde rechten voor een bepaalde onderneming toegewezen te kunnen krijgen.

De huidige situatie ziet er versimpeld als volgt uit:

onderneming

parentid

users

userid

rechten

userid

recht

De parentid in de tabel onderneming geeft aan onder welke andere onderneming (holding) deze valt. Hierdoor vallen er meerdere users (welke gekoppeld zijn aan een onderneming) onder één onderneming of meerdere ondernemingen.

In de applicatie kan je verder een user aan een onderneming koppelen zonder rechten te geven. De bedoeling is dat deze automatisch geërfd worden van de hoofdonderneming.

Om de rechten hiervoor vast te leggen lijkt het mij gewoon het handigst om aan de tabel rechten een onderneming-id toe te voegen. Hier kan dan een recht aan toegevoegd worden om aan te geven of het mogelijk is om voor die user icm die onderneming rechten te geven of niet.

Mijn collega lijkt het beter om de volgende tabel erbij toe te voegen. Hierin geef je dan apart aan of het mogelijk is om voor de user icm die onderneming rechten in te stellen of niet.

userondernemingen

userid

ondernemingid

type

Mij lijkt het juist dubbelop. Aangezien je de relatie al uit de tabel onderneming en user kan halen daarnaast is er nog een tabel waaruit deze relatie te halen is En aan de hand van de tabel rechten kan je dan zien of de gebruiker rechten toegewezen kan krijgen voor die onderneming.

Wat is jullie mening als je kijkt naar efficiency, snelheid en overzichtelijkheid?

Mocht ik belangrijk info zijn vergeten of is het niet duidelijk dan hoor ik het wel.

[armageddon_2k1]

Mag ik vragen hoe je zonder die koppeltabel weet bij welke onderneming welke user hoort?

Die van je collega is slim als je zou willen dat een user bij meerdere ondernemingen zou horen. Is dit niet nodig, dan volstaat een ondernemingid in de usertabel.

[ Voor 48% gewijzigd door armageddon_2k1 op 05-10-2010 18:20 ]

[Currahee]

Je verhaal is niet al te duidelijk, maar ik zou het op de volgende manier doen (voor zover ik het begrijp).

Bedrijven

• Bedrijfid
• Standaard rechten (dus bij gewone koppeling)

Users

• Userid

Koppeling user / bedrijf (zodat er meerdere bedrijven aan één user kunnen worden meegegeven)

• Koppelingid
• Userid
• Bedrijfsid
• Rechten (0 = Standaard Rechten, 1 = Speciale Rechten)

Eventueel zou je dan nog een aparte tabel kunnen maken met daarin de speciale rechten gekoppeld aan een koppelingsid, maar ik weet niet hoe complex dat in elkaar zit.

[cariolive23]

Currahee schreef op dinsdag 05 oktober 2010 @ 18:56:
• Rechten (0 = Standaard Rechten, 1 = Speciale Rechten)

Wat voor de één standaard is, is voor de ander speciaal. Dit zegt dus helemaal niks, heeft dus geen zin. Geef rechten of geef geen rechten, daar zit niks tussenin. Ik ben van mening dat rechten altijd speciaal zijn, anders had je ze niet.

Kijk ook eens naar ACL of RBAC, al is het maar om ideeën op te doen over het inrichten van permissies.

[nemo55]

armageddon_2k1 schreef op dinsdag 05 oktober 2010 @ 18:20:
Mag ik vragen hoe je zonder die koppeltabel weet bij welke onderneming welke user hoort?

Een id in de ondernemingstabel geeft aan welke (hoofd)user er bij dat bedrijf hoort. Een user heeft weer (sub)users onder zich. Die subs zijn in dit voorbeeld even niet belangrijk dus vergeet die maar weer.

Die van je collega is slim als je zou willen dat een user bij meerdere ondernemingen zou horen. Is dit niet nodig, dan volstaat een ondernemingid in de usertabel.

Het is inderdaad de bedoeling om een user onder meerdere ondernemingen te laten vallen. Dit word echter al gedaan dmv een id van een andere user bij de user zelf op te slaan wat dan fungeert als een soort van beheerder-id. Bij die "beheerder"(user) staat dan het id van het bedrijf waar die bij hoort.

Geen handige structuur, maar helaas wel één waar we voorlopig nog even mee moeten werken.

Currahee schreef op dinsdag 05 oktober 2010 @ 18:56:
Je verhaal is niet al te duidelijk, maar ik zou het op de volgende manier doen (voor zover ik het begrijp).
...

Jouw structuur is inderdaad een juiste voor de situatie. Helaas kunnen/mogen we dit nog niet wijzigen. Dit is te ingrijpend op de bestaande situatie dus we proberen het met een zo klein mogelijke aanpassing.

cariolive23 schreef op dinsdag 05 oktober 2010 @ 21:30:
[...]

Wat voor de één standaard is, is voor de ander speciaal. Dit zegt dus helemaal niks, heeft dus geen zin. Geef rechten of geef geen rechten, daar zit niks tussenin. Ik ben van mening dat rechten altijd speciaal zijn, anders had je ze niet.

Misschien bedoelde hij afwijkende rechten ipv standaard rechten.

Kijk ook eens naar ACL of RBAC, al is het maar om ideeën op te doen over het inrichten van permissies.

Bedankt, ik al er zeker naar kijken, maar ik ben bang dat dat ook naar een te ingrijpende herstructurering zal leiden voor het moment. Er zal echt gekeken moeten worden naar één van de twee genoemde oplossingen.

[ Voor 7% gewijzigd door nemo55 op 06-10-2010 01:15 ]

[RobIII]

Waar hoort mijn topic?
PRG >> SEA

nemo55 schreef op woensdag 06 oktober 2010 @ 01:13:
Helaas kunnen/mogen we dit nog niet wijzigen. Dit is te ingrijpend op de bestaande situatie dus we proberen het met een zo klein mogelijke aanpassing.

Dan is het wel handig dit soort zaken voortaan even in je topicstart te vermelden; nergens in je topicstart rep je over dat het zoveel mogelijk moet blijven zoals het is en/of waar je dan wel/niet aan kunt/mag komen. Je hebt het over "hoe we een database het beste kunnen wijzigen om een nieuwe functionaliteit toe te voegen" maar nergens zie ik deze beperkingen terug in je topicstart waarmee je impliceert dat je dus kunt wijzigen wat je wil.

[ Voor 77% gewijzigd door RobIII op 06-10-2010 01:54 ]

[nemo55]

Excuses (ook voor het misplaatsen van het topic). Dacht dat ik wel duidelijk was geweest dat het ging om de twee opties die genoemd werden in de ts, maar na het lezen van de reacties en het nogmaals doornemen van de ts is dat inderdaad niet helemaal het geval.

Daarnaast is het natuurlijk niet erg als mensen met andere oplossingen aankomen die ook minimale wijzigingen vereisen en eventueel toepasbaar zouden zijn, maar het gaat mij in eerste instantie om die twee keuzes.

[Hydra]

Ik zou niet voor een User > Rechten systeem gaan maar voor een User > Role > Rechten systeem gaan. Je kunt rechten toewijzen aan rollen, en users een rol laten uitvoeren. Zo heb je bijvoorbeeld een generieke "Admin" rol, maar kun je ook rollen per bedrijf hebben. En een user kan meerdere rollen hebben.

[nemo55]

Dit is alleen handig als er sprake is van rollen. In deze applicatie zijn die er niet en kunnen verschillende users totaal verschillende rechten hebben op bepaalde onderdelen van de desbetreffende onderneming welke ingesteld worden door de hoofdgebruiker van de onderneming.

[Hydra]

nemo55 schreef op woensdag 06 oktober 2010 @ 16:44:
Dit is alleen handig als er sprake is van rollen. In deze applicatie zijn die er niet en kunnen verschillende users totaal verschillende rechten hebben op bepaalde onderdelen van de desbetreffende onderneming welke ingesteld worden door de hoofdgebruiker van de onderneming.

Er kan prima sprake zijn van 1 user/rol, dat doet er verder niet toe. Het gaat me er om dat je users loskoppelt van rechtensets.

[nemo55]

Hydra schreef op woensdag 06 oktober 2010 @ 17:10:
[...]


Er kan prima sprake zijn van 1 user/rol, dat doet er verder niet toe. Het gaat me er om dat je users loskoppelt van rechtensets.

In de huidige situatie is dat ook zo en deze scheiding zou ik ook zo willen houden. Met de wijziging van mijn collega leg je iets wat met rechten te maken heeft vast in een aparte tabel (usersondernemingen) wat voor mij nogal onlogisch overkomt en de hele dataset alleen maar verwarrender maakt dan het al is.

Qua performance zou het misschien sneller kunnen zijn omdat je dan snel even in een kleine tabel kan kijken of een user wel gekoppeld is (en dus rechten toegewezen kan krijgen) op die bepaalde onderneming.

Het druist alleen tegen mijn principes in om extra tabellen aan te gaan maken om data te verkrijgen die in principe al uit de database te halen valt en dat terwijl de extra functionaliteit al te verkrijgen is met een simpele toevoeging van een extra type aan rechten.

Ik moet alleen hem nog zien te overtuigen

[Ventieldopje]

voeg het ondernemings id (parentid?) toe aan de rechten tabel, en maak een nieuwe regel aan voor elke onderneming de gebruiker in zit, zo kun je de rechten per onderneming instellen

[nemo55]

Phas0r schreef op woensdag 06 oktober 2010 @ 23:07:
voeg het ondernemings id (parentid?) toe aan de rechten tabel, en maak een nieuwe regel aan voor elke onderneming de gebruiker in zit, zo kun je de rechten per onderneming instellen

precies

Om de rechten hiervoor vast te leggen lijkt het mij gewoon het handigst om aan de tabel rechten een onderneming-id toe te voegen.

Alleen dan niet met het parent-id maar het id van de onderneming zelf. parent-id geeft aan van welke andere onderneming deze een dochter is.