Rechtesystem (Performance)

**hostbar_danny** · 23-02-2012, 19:46

Ich kenne deine Struktur nicht, aber warum liest du nicht nur die Navigationspunkte aus die der User auch sehen darf, anstatt erst einmal alle auszulesen und dann zu prüfen ob man den Einzelnen anzeigen darf?

Gruß Danny

**AmicaNoctis** · 23-02-2012, 19:59

Hallo,

du könntest deine hierarchische Rechtestruktur in der DB als Nested Sets abbilden. Mit einer N:M-Beziehung zwischen dieser Tabelle und der Benutzertabelle bildest du die einzelnen Nutzerberechtigungen ab. Dann kannst du für den aktiven Benutzer mit einem einzigen gejointen Select-Statement den kompletten Rechtebaum abfragen.

Gruß,

Amica

**darton** · 23-02-2012, 20:37

Originally posted by hostbar_danny View Post

Ich kenne deine Struktur nicht, aber warum liest du nicht nur die Navigationspunkte aus die der User auch sehen darf, anstatt erst einmal alle auszulesen und dann zu prüfen ob man den Einzelnen anzeigen darf?

Gruß Danny

Da hast du natürlich Recht. Hab mich wohl bisher zu oberflächlich um meine Problem gekümmert. So werd ichs machen.

Nested Set ist glaube ich in meinem Fall nicht notwendig.

**AmicaNoctis** · 23-02-2012, 23:20

Originally posted by darton View Post

Nested Set ist glaube ich in meinem Fall nicht notwendig.

Nested Sets sind nie zwingend notwendig, aber äußerst sinnvoll und da es laut Threadtitel um Performance geht, gibt es bisher nichts, was diese Anforderung besser erfüllen würde.

**combie** · 24-02-2012, 05:31

Ich glaube er/sie/es meint, dass kein hierarchisches System notwendig wäre.

**AmicaNoctis** · 24-02-2012, 06:31

Originally posted by combie View Post

Ich glaube er/sie/es meint, dass kein hierarchisches System notwendig wäre.

Okay, dann hab ich das falsch verstanden. „Ich schütze damit komplette Seiten, aber auch einzelne Buttons“ klang irgendwie hierarchisch.

**combie** · 24-02-2012, 06:47

Ich sehe auch keine praktikable Alternative dazu.

**litterauspirna** · 24-02-2012, 11:41

Ich würde im dem Fall mir eine kleine und einfache ACL bauen. Die nimmt ja immer Rollen entgegen und die Default Role ist ja meist Guest.

So kann man diese ACL als ein Plugin vor den Auf und Zusammenbau der Anwendung initialisieren und hat den Role Wert den man braucht.
In den weiteren Anwendungsteilen kann man dann darauf reagieren, jenachdem wie eine Anwendung aufgebaut ist muss das eben hinein implementieren.

Nested Sets sind zwar sehr nützlich, aber in dem Fall finde ich nicht wirklich nötig. Und auf eine DB würde ich diese Geschichte schon mal gar nicht festnageln, finde das sehr unflexibel. Eine Schnittstelle bzw. Adapter wo die Role herkommt und dann kann ich ohne große Anpassungen und Eingriffen sehr einfach mal umstellen.

Gruß Litter

**combie** · 24-02-2012, 15:59

Die nimmt ja immer Rollen entgegen und die Default Role ist ja meist Guest.

Und die anderen Rollen erben dann von Gast.
Womit du dann auch schon bei Bäumen wärst.

Und auf eine DB würde ich diese Geschichte schon mal gar nicht festnageln,

Eine DB gehört zur Anforderung des TE. (egal, was ich davon halte)
Und damit ist man entweder bei Dutzenden von Anfragen, oder bei Nested Sets, dank des Baumes.

**litterauspirna** · 25-02-2012, 12:08

Wenn du eine ACL verwendest befindest du dich bei der Abarbeitung dieser aber nicht mehr in der DB, also liegt dein Baum in der ACL und nicht in der DB und somit brauchst du kein Nested Sets mehr. Eine ACL bildet man nie über eine DB ab. In der DB wird maximal die Role des Benutzers gespeichert und bei der Authentifizierung wird diese in die Session gespeichert.

Bei jeder Action gibt man eben entsprechende Parameter an die ACL weiter.

Und schon hat man ne Rechteverwaltung von der DB gelöst, wo die eben auch nicht hin gehört und braucht kein Nested Sets mehr.

Auserdem kann ich keinen Satz beim TE sehen der besagt das er die Rechteverwaltung zwingend in die DB ablegen will, auch nicht das die DB für die Rechteverwaltung unbedingt Anforderung ist.

Ich wüsste nicht warum man eine DB belasten muss um ein Rechtesystem zu managen.

Rechtesystem (Performance)