Nested Set - Strukturfrage/n

**PHP-Desaster** · 17.11.2009, 08:15

Frage 1: Ein Nested Set kann Datenknoten beliebig tief anlegen, ganz egal welche Daten du dort hinein packst.

Frage 2: Wenn du diese tiefe Verästung benötigst und du keinen Fehler im Konzept hast, macht es natürlich Sinn. Und natürlich wird es Komplizierter. Aber so einen Nested Set willst du eh nicht per Hand in der Datenbank pflegen, dafür ist der Ansatz zu komplex. Mehr als eine Handvoll Knoten bekommt man per Hand kaum noch bewältigt.

Frage 3: Ich würde die Vererbung der Gruppen, die Rechte und die eigentliche Navigationsstruktur auseinanderziehen. So verbaust du dir die tiefere Schachtelung von Gruppen und das Vererben von Rechten.

**medium22** · 17.11.2009, 19:22

Hallo,

Klingt interessant.

Das heisst also, es würde mehr Sinn machen, wenn ich Navigation, Gruppen und Rechte jeweils einen eigenen Baum 'pflanze' und denen dann jeweils die "root_id" mitgebe, richtig?

Würde dann ja für diesen Zweck 3 Bäume ergeben..

Navigation
--> Gruppen_id
----> Link 1
----> Link 2
usw.

Gruppen
--> Gruppen_id
--> Gruppenname
...

Rechte
--> Recht
----> Gruppen_id

Aber wie kommt man dann zb. dazu, dass ein Administrator alle diese besitzen/sehen kann? Oder liegt meine Aufspaltung schon wieder nicht richtig?

**PHP-Desaster** · 17.11.2009, 21:04

In deiner Struktur hast du jetzt nur einen Baum, nämlich die Navigation. Weder deine Gruppen noch deine Rechte besitzen bei dir eine Baumstruktur.

Ich dachte mehr an sowas:

Code:

+ Navigation
|-+ Link 1
| |- Unterlink 1
| `- Unterlink 2
`-- Link 2

+ Gruppenbaum
|-+ Gruppe 1
| |- Untergruppe 1
| `- Untergruppe 2
`-- Gruppe 2

Für die Rechte reicht eine einfache Lookup-Liste:

Code:

Rechte:
- ID des Navigations-Knoten
- ID des Gruppen-Knoten
- Recht

Dann kannst du deine ACL sogar noch bei Bedarf mit Vererbung versehen.

**AmicaNoctis** · 17.11.2009, 22:46

Hallo Raffi,

wenn du eine Tabelle als Nested Set konzipierst, sollte sie trotzdem gleichartige Datensätze enthalten (nur Benutzergruppen oder nur Rechte).

Wenn bei dir die Rechte auch hierarchisch sind (macht ja oft Sinn), bietet sich dafür auch ein Nested Set an, aber wieder in einer anderen Tabelle.

Dennoch frage ich mich, ob deine Benutzergruppen wirklich Benutzergruppen sind oder versteckte Rollen. Wenn die Rechte von der Benutzergruppe anhängig sind, ist es eine Rolle. Wenn nur andere oder gar keine Benutzerattribute durch die Gruppenzugehörigkeit bestimmt werden, ist es wirklich nur eine Gruppe.

Kannst du mal deine aktuelle DB-Struktur (ohne Daten) als CREATE-TABLE-Statements posten?

Gruß,

Amica

**medium22** · 18.11.2009, 06:54

Hallo,

Die DB-Struktur wovon genau? Ein Grossteil ist bisher nur bei meinen Notizen vorhanden und noch nicht in einem System.

Hm.., wohl eher Rollen - aber auch wieder nicht.

Rechte werden (bzw. sollten dann..) durch die zugehörigkeit einer Gruppe gesetzt. Aber ich möchte auch einzelne Rechte an Benutzer vergeben können - also sowohl als auch. Hauptaufgabe der Gruppen wird es aber sein die Rechte zuzuweisen, also mehr eine Rolle als eine Gruppe.

Ziel dieser Nested Sets sollte es ja sein, mit einem Query alles nötige für die schnellste (bzw. performanceärmste) Seitenausgabe (bzw. Seitenaufbau) zu sorgen. Im aktuellen System - das absolut für (verzeiht den Ausdruck) n'Arsch ist - ist die Struktur so undenkbar schlecht, dass bei jeder Aktion mehrere Querys gesendet werden und X Daten verarbeitet werden müssen. Sind dann mal einige Benutzer gleichzeitig online merkt man extrem wie langsam das ganze wird. Grade weil ich "nur" ein Hostingpaket nutze und keinen Server, sollte ich schleunigst an die performance denken und nicht nur an einfachen Code.

**AmicaNoctis** · 18.11.2009, 09:59

Hallo,

alles benötigte liefert auch ein Join, was der Join aber nicht kann, ist in beliebige Tiefe einer hierarchischen Struktur abzusteigen. Mit einem Join musst du jede Ebene oder Generation einzeln ansprechen, mit einem Nested Set sprichst du Teilbäume an.

Trotzdem hast du mehrere Tabellen, die am Ende gejoint werden und dir damit die vielen Abfragen ersparen. Die Benutzertabelle macht als oder in einem N'Set keinen Sinn (es sei denn du willst noch ein Genealogieportal aufbauen).

Die Kombination aus beiden macht es also.

Amica

**PHP-Desaster** · 18.11.2009, 11:27

Zitat von AmicaNoctis Beitrag anzeigen

Die Benutzertabelle macht als oder in einem N'Set keinen Sinn (es sei denn du willst noch ein Genealogieportal aufbauen).

Stimmt so nicht ganz. Du kannst Gruppen in einem NestedSet implementieren, um Vererbung von Rechten auf Untergruppen zu ermöglichen. Sowas wie:

Code:

+ Angestellte
|-- Angestellter der Abteilung AB
|-- Angestellter der Abteilung XY
+ Projektmitarbeiter
|-- Projekt ABC
`-- Projekt XYZ

Aber das ist natürlich nur wichtig, wenn die Benutzerverwaltung entsprechend feingranular sein soll.

**AmicaNoctis** · 18.11.2009, 11:32

Du hast mich falsch verstanden. Gruppen sind keine Benutzer und gehören in eine Extratabelle, die durchaus als N'Set gestaltet sein kann. Ich sprach aber von Benutzern selbst und die sind nicht hierarchisch (außer wie gesagt bei Familienforschungsprojekten). Daher machen für die Benutzertabelle N'Sets keinen Sinn, bei Benutzergruppen, Rollen, Rechten gegebenenfalls schon.

**PHP-Desaster** · 19.11.2009, 16:32

Zitat von AmicaNoctis Beitrag anzeigen

Du hast mich falsch verstanden. Gruppen sind keine Benutzer und gehören in eine Extratabelle, die durchaus als N'Set gestaltet sein kann. Ich sprach aber von Benutzern selbst und die sind nicht hierarchisch (außer wie gesagt bei Familienforschungsprojekten). Daher machen für die Benutzertabelle N'Sets keinen Sinn, bei Benutzergruppen, Rollen, Rechten gegebenenfalls schon.

Alles klar, dann habe ich dich in der Tat falsch verstanden.

Nested Set - Strukturfrage/n