Theoretische Fragen zum Design einer Datenbank

[sono]

Morgen .

Ich bin gerade dabei ein Rechtesystem für eine Webanwendung zu planen.

Vom Design her hab ich genau 2 (relativ leicht) zu implementierende Modelle entwickelt .

Eines verwaltet das ganze Rechtesystem in einer einzigen Tabelle , mit einigen wenigen Spalten , aber über Kurz oder Lang wohl sehr vielen Einträgen .

Das andere Modell hat für jeden Relevaten Bereich eine eigene Tabelle mit relativ vielen Spalten und dadurch wohl ca. um den Faktor 100 ( PI mal Schnauze geschätzt ) weniger Datensätze als das Modell mit der einzigen Tabelle.

Mit dem Ersten Modell habe ich viele Daten in wenig Tabellen , im Zweiten Modell habe ich viele Tabellen mit weniger Daten.

Nach meiner Logik ( dem was ich darunter verstehe ) sollte das 2te Modell Performanter laufen als das ein Tabellen Modell .

Es geht Hauptsächlich um die Perfomace , da bei allen Relevanten Aktionen geprüft werden soll , ob der User , oder eine Gruppe in der er ist überhaupt das Recht dazu hat, bzw was der User in der Anwendung zu Gesicht bekommt und was nicht.

Für kleiner ( oder auch größere Tipps ) wäre ich sehr dankbar.

Gruß Sono

[onemorenerd]

Kannst du das Ein-Tabellen-Modell mal genauer erklären? Ich habe den Verdacht, wenn man es ordentlich Normalisiert, kommt so ungefähr das Mehr-Tabelle-Modell raus, kann das sein?

[sono]

Jain . Dass kommt drauf an aus welchem Blickwinkel man das betrachtet.

Also mal kurz was zur Art des Sicherheitssystems :

Ich habe vor eine Klasse zu schreiben deren Objekt in die Session kommt.
Eine Methode prüft in jeder Relevanten Aktion ob der User das Recht dazu hat diese Aktion auszuführen .

Die 1 Tabellen Methode ist sehr einfach gestrickt . Sieht ungefähr so aus :

Tabellen :

UID ( die USERID )
BEREICH ( der Bereichsname auf den Zugegriffen werden soll )
RECHTE ( bool darf / darf ned )

Also am Anfang jedes Bereiches ungefähr sowas:

if ( ! $SECSYS->UserValid(  $UID , "Verwaltung" )){
  throw new secsys_Exception($NO_ACCESS_MSG);
} 

Ich hab dann im Projekt Funktionen die dem Bereich XYZ angehöhren und wenn ein user ABC diese verwenden möchte ist darin eben ein Objekt des Sicherheitssystem dass Prüft ob der User dass darf , oder eben nicht .

Diese Klasse Prüft anhand der UID und des Bereiches ob der User das darf oder nicht.

Sehr sehr einfach aufgebaut , und programiertechnisch sehr einfach und damit wohl relativ Fehlerfrei implementierbar.


Im Anderen Fall , habe ich die Hauptbereiche des Systems in der Datenbankenstruktur nachgebildet und eine wesentlich mehr Optionen in den Rechten eingebaut. Dafür muss ich auch wesentlich mehr Parameter übergeben und verarbeiten .

Ich hab allerdings wesentlich weniger Bereiche die zu verwalten sind und setzte für diese Bereiche dann entsprechende Berechtigungen wie lesen , updaten schreiben und noch einigen andere.

Vom Programmieraufwand auf jeden Fall Wesentlich mehr Arbeit.

Im Endeffekt kann ich aber mit beiden Modellen genau gleich viel machen , also ich kann alles in Modell 1 umsetzen wass auch Modell 2 kann.

Ich hab mir mal irgendwann abgewöhnt mir beweisen zu müssen, dass ich den komplizierteren Weg auch gehen kann und bevorzuge seit dem eigentlich erfolgreich relativ einfach Lösungen von Problemen.

Nur kanns halt passieren dass Modell 1 mit zunehmender Projektgröße auf dem System mal eben ein paar 1000 bis 10000sende Bereiche Pro User Anlegen muss.

Bei Modell 2 verteil sich dass eben auf mehrer Spalten und Tabellen .

Sowie ich das einschätzen kann ist das 2te Modell bei großen Projekten in System wohl wesentlich schneller oder ?

Gruß Sono

[onemorenerd]

Mir fällt auf, dass du keine Gruppen und -rechte vorgesehen hast. Das bedeutet, ein Admin, der ein neues Objekt anlegt, muß für alle User einzeln festlegen, ob sie Zugang zum Objekt haben. Das halte ich für keine gute Idee, wirst du sehr bald drüber stolpern und alles umbauen müssen ... also lieber gleich.

Die beiden Ansätze ähneln sich tatsächlich, denn wenn man die Objekte in der einen, großen Tabelle nach ihrer Zugehörigkeit in die Hauptbereiche trennt, bewegt man sich schon stark in Richtung deiner Mehr-Tabellen-Idee. Zudem gewinnt man bei diesem Schritt schon die Möglichkeit, Zugang auf Bereichsebene zu beschränken ... was auch mit einer Tabelle möglich wäre, aber kaum so performant umsetzbar. Ich frag mich übrigens, wie du mit einer Tabelle überhaupt die Hauptbereiche abbilden willst.

Du wirst doch sicher nicht nur die Rechte in einer DB speichern, sondern auch Eigenschaften der Objekte und Bereiche, Zugehörigkeiten (Obj. x ist in Bereichen y und z) usw.
Wenn du das ordentlich normalisierst, wird es viel einfacher sein, auch die Rechte mit mehreren, normalisierten Tabellen zu verwalten. Normalisieren kann übrigens auch bedeuten, sich an der Semantik und den Beziehungen der abzubildenden Objekte zu orientieren.

[sono]

Gruppenrechte hab ich auch mit eingeplant. Die waren dann in ner 2ten Tabelle die ähnlich simpel war.

Ich hab aber mittlerweile von der ein Tabellen ( also mit Gruppen 2) Modell Abstand genommen , eben wegen der Performance , und weils mir dann irgendwie doch etwas zu einfach war, und weil das eigentliche Verwalten der Rechte aus dem System heraus dann zu aufwendig werden könnte wegen der ewigvielen Bereiche.

Dein letzer Post hat mir noch ein paar Anregungen gegeben wie ich das ganze umsezten kann.

Ich denke mal so langsam weiß ich wie ich das hinbekomme .

Danke für deine Hielfe .

Gruß Dominik

[onemorenerd]

Wenn es letztlich keine sehr spezifische, auf einen bestimmten Einsatzzweck zugeschnittene Umsetzung wird, sondern eine, die man generell für Rechteverwaltung nutzen kann, dann wäre es ganz nett, wenn du die DB-Struktur oder vielleicht sogar auch die zugehörigen Klassen, Funktionen, Codeabschnitte posten oder anhängen würdest. Nachfolgende (suchende) User wären dir dankbar.

Viel Erfolg!

[sono]

Das ganze System sehr stark modular aufgebaut ist .

Sprich ich habe ein Basissystem das nichts anderes macht als User und Gruppen zu verwalten, die Zugriffskontrolle und die Module verwaltet . Die eigentlichen Funktionen kommen dann über die Module , deshalb war die Umsetzung des Sicherheitssystemns nicht ganz so einfach war wie bei einem starren System.

Das mit dem veöffentlichen ist nicht ganz so einfach , ich bin da ein wenig an ein paar Verträge gebunden in denen drin steht dass ich diese Arbeit lieber nicht veröffentlichen sollte .

Aber ich werde sobald das Sicherheits System sich bewährt hat , und wenn es zeitlich passt einen stark vereinfachten Prototyp mit Tutorial veröffentlichen , so dass man nachlesen kann wie man so etwas angehen kann.

Ich hab mir vorgenommen aus der Entwicklerdoku und dem Wiki eine Howtoseite zu machen sobald alles fertig ist . Wenn alles fertig ist , haben wir genügend Probleme gelöst und somit auch genügend Material dafür.

Danke nochmal für deine Anregungen.

Gruß Dominik