Gruppen- / Subgruppenzuweisung, Denkanstoss

[medium22]

Hallo zusammen,


Zur Zeit brüte ich ein Projekt aus welches in sich viele Hauptgruppen und Subgruppen kennen sollte. Sowohl die einen als auch die anderen sollten an bestimmte (und änderbare!) Nutzerrechte gebunden sein. Mir stellt sich nun die Frage, wie (oder wieviele) Tabellen es dafür geben sollte sodass man damit anständig und resourcenarm arbeiten kann.

Meine Idee (eine eher bescheuerte, geb' ich zu!) bisher ist folgende...

Tabelle "User"
--> beinhaltet Dinge wie Usernamen, Passwort, Hauptgruppe, Subgruppe/n (durch Komma getrennt), und weiteres was speziell zum User selbst gehört

Tabelle "User_Gruppen"
--> id, bennennung

Tabelle "User_Sub_Gruppen"
--> id, benennung, rechte (durch komma getrennt)

Tabelle "Rechte"
--> benennung, titel

Tabelle "User_Rechte"
--> User_Id, recht, sub_gruppen_id

Ggf. dazu und/oder vereinzelt noch View's davon (oder zusammengelegt) anlegen..

Grade das trennen durch Kommas ist nicht wirklich eine normalisierte Datenbank aber etwas anderes fällt mir grade nicht ein. *schlafmangel on*


Wie gesagt, dieses Projekt steht noch in der Planungsphase, man muss also nichts bedenken wie z.B. das umschreiben von Skripten, etc.


Für Ideen und/oder Ansätze bin ich dankbar.


Gruss

[AmicaNoctis]

Hallo,

ich würde eine Gruppentabelle machen, die sich selbst referenziert:

group
------
id
name
parent_fkey => group.id

Dann eine Benutzertabelle völlig ohne Gruppenangaben. Da ein Benutzer offenbar in mehreren Gruppen sein kann und mehrere Benutzer in derselben Gruppe, hast du eine klassische n:m-Beziehung, die man mit einer weiteren Tabelle abbildet:

group_x_user
---------------
id
group_fkey => group.id
user_fkey => user.id

Gruß,

Anja

Edit: das mit den Rechten dann natürlich analog, z. B. Tabelle group_x_right

[medium22]

Hallo,


ich merke, ich habe vergessen das es um eine MySQL-Datenbank geht und ich diese nur im MyISAM-Format verwenden kann. Deine Ausführungen sagen mir, dass dort InnoDB gemeint ist - oder lieg ich da falsch? Denn das mit dem Referenzieren kenne ich ansonsten nicht wirklich, war nur der Meinung bzgl. InnoDB mal sowas gelesen zu haben.


Gruss

[AmicaNoctis]

Du kannst Fremdschlüssel auch in MyISAM benutzen, allerdings werden dann keine Constraints erzeugt. Auf Deutsch, es wird nicht überprüft, ob der Fremdschlüsselwert, den du einträgst, in der Elterntabelle als Primärschlüsselwert existiert.

Ich rate unbedingt zu InnoDB.

[medium22]

Wenn ich könnte würde ich das, aber die steht mir leider nicht zur verfügung. Mit ein Grund warum ich mir solche Gedanken um die Struktur machen muss - es hängt im Endeffekt viel Code davon ab (eben wegen der fehlenden Beziehungen...)

[AmicaNoctis]

Die Beziehungen kannst du, wie gesagt, in MyISAM genauso machen. Der Unterschied ist, dass du fehlerhafte Verweise eintragen könntest, die bei InnoDB vorher auf referentielle Integrität geprüft werden und bei Verletzung derselben eine Fehlermeldung zur Folge haben.

Wenn du sauber programmierst und beim Löschen von Datensätzen daran denkst, vorher jeweils auch die abhängigen Kinddatensätze zu löschen und beim Einfügen gültige Schlüsselwerte benutzt, kannst du auch in MyISAM prima mit Beziehungen arbeiten.

[combie]

Du kannst das auch in myisam erledigen. Bist dann aber selber für die referenzielle Integrität zuständig.


dieses ist auf jeden Fall eine schlechte Idee:

(durch komma getrennt)

Denn es ist ein grober Verstoß gegen die erste Normalform.
Die 5 Normal Formen

[onemorenerd]

Wie stellst du dir das denn vor mit der Rechtezuweisung? Hat eine Gruppe Rechte, hat ein User welche? Hat eine Subgruppe Rechte? Erbt sie welche von der/den Muttergruppe/n, bekommt sie direkt welche zugewiesen? Wie löst du Konflikte zwischen Gruppen-, Subgruppen und Userrechten?

[medium22]

Das sind eben Dinge die ich irgendwie bedenken will bevor ich das anfange zu strukturieren.

Die Hauptgruppen sind in dem Sinne nur Zwecks Navigation & Seitenbenutzung vorhanden und haben keine fest zugewiesenen Rechte. Jede Hauptgruppe hat einen eigenen Bereich im System welches wiederum so modular gestaltet wird, dass Skripte für jede Hauptgruppe benutzt werden können. Daher auch diese Hauptgruppe, zwecks speichervorgängen (aus welcher solcher kam ein Eintrag, etc...)

Die Rechte ansich erhält der User durch die Subgruppen. Dh. also, dass ein User sowohl in mehreren Hauptgruppen als auch in mehreren Subgruppen sein kann. Es kann also auch sein, dass ein User der in mehreren Subgruppen ist, dasselbe Recht mehrfach hat und genau das wollte ich eigentlich vermeiden. Aber da ich keine InnoDB nutzen kann, werde ich da um aufwändige Konstrukte im Code selbst wohl nicht rumkommen.

[onemorenerd]

Huh, Gruppen sind also Seitenbereiche?! Das scheint ja ein sehr schräges Konzept zu sein. Da du noch in einer sehr frühen Planungsphase steckst, besteht kein Zwang dazu und ich rate dir davon ab. ;-)

Seitenbereiche sind URL-Präfixe wie /content, /profile oder /admin. Ich sehe keinen Grund, dafür Gruppen zu definieren. Die Berechtigungen lassen sich, wie du selbst schon bemerkt hast, allein mit Subgruppen- und direkten Userrechten abbilden.
Also keine Gruppen und Subgruppen, sondern einfach nur Gruppen mit der Funktion, die du für Subgruppen angedacht hast - für Seitenbereiche alias URL-Präfixe was anderes ausdenken.

... und dann nennen wir es Rollen statt Gruppen und schon sind wir beim Standardschema ACL und Router. Das steckt in vielen Systemen (z.B. Drupal) und Frameworks (z.B. Zend Framework). Schau es dir mal an!

[medium22]

Guten Morgen,


Habe mir das Drupal mal runtergeladen und mich durch den Inhalt gewühlt. Ich muss zugeben, das ist für mich mind. 2 Stufen zu hoch. Das mein Projekt bzw. die Ideen dazu eine solche komplexität annimmt hätte ich niemals erwartet. Zumal mein Gedankenzug mit den Haupt- / Subgruppen in dem Sinne (jedenfalls von der ersteren her) sehr einfach gedacht war.
Beim LogIn würden alle zum User gehörenden Rechte in der Session abgelegt werden (Server vor zu vielen Querys schonen). So dachte ich mir dann, warum nicht einfach die Id der Hauptgruppe verwenden? zB. seite.php?g=2... würde für die Hauptgruppe mit der Id 2 stehen. Würde ein User die URL manipulieren wollen, so würde der Fehler ja dann aufgrund der fehlenden Session (wenn diese Hauptgruppe nicht zu ihm gehören sollte) ausgegeben werden. Eigentlich eine ganz simple Idee, dachte ich jedenfalls.

Vielleicht muss ich die Planungsideen etwas zurück schrauben und sie mehr meinem Wissen anpassen.

[onemorenerd]

Du sollst dir nicht das ganze Drupal ansehen sondern nur das Routing, Rollen und Permissions. Muss auch nicht Drupal sein, das gibt es in vielen anderen Systemen auch. Zugegeben, es ist in einem völlig unbekannten System schwer zu finden, aber ich hatte ja ebenfalls das Zend Framework genannt - Zend Framework: Documentation, Zend Framework: Documentation

[medium22]

Und weil ich Heute runde 650 km auf der Autobahn verbrachte und dabei viel Zeit zum grübeln hatte, kann ich nun sagen.. "Ist es doch Wahnsinn und doch hat es Methode!"
Mir ging es im groben darum, ein möglichst einfaches Handling der Rechte zu gewährleisten - sowohl im System selbst als auch beim Login und der Navigation.
Lege ich mir nun folgende Tabellen an, so würden alle genannten Bedingungen zutreffen. Nicht schön aber irgendwie doch sehr praktisch ohne InnoDB..

user: id, name, ....
gruppen: id, name
subgruppen: id, name
rechte: id, name, bezeichnung
user_rechte: user_id, recht, gruppen_id, subgruppen_id

Daraus lässt sich schliessen, das hauptsächlich nur auf die letzte Tabelle zugegriffen wird. Es spielt dann auch keine Rolle mehr wenn ein Recht mehrfach durch versch. Subgruppen an denselben User vergeben ist. Schliesslich landet das sowieso alles in einem Array welches zuerst durch ein array_unique und dann durch ein array_values gejagt wird. Der Vorteil daran ist, dass beim ändern der Rechte einer Subgruppe nicht erst kontrolliert werden muss ob der User dieses (zb. entfernte Recht) nicht auch noch durch eine andere Subgruppe benötigt. So kann man einfach das Recht entziehen, und wenn er es doch haben müsste durch eine andere Subgruppe, so hat er es dann noch immer. So wäre alles in einer Tabelle was man braucht und diese kann ohne weiteres auch erweitert werden wenn es sein muss. So bleibt alles dynamisch/flexibel.. Nachteil.., es ist wahrscheinlich nicht die Normalform... Aber in meinem Dickschädel müsste das so eigentlich ganz gut funktionieren..