Datenbankdesign über mehrere Ebenen

[mo2402]

Hallo,

ich bräuchte für meine Firma ein Datenbankentwurf für eine extrem abgespeckte Version eines CRM Systems. Die Struktur im Betrieb ist wie folgendes Schaubild aufgebaut:



Die Betriebsleitung hat einblick in ALLE tätigkeite, egal ob von Regionalleiter, oder Vertriebsleiter etc.

Die Regionalleiter haben natürlich nur einblick in die Sachen die dennen Untergeordnet sind und nicht die, des anderen. Und so geht das halt immer weiter das die Übergeordneten immer den untergeordneten "in die Karten" gucken können aber nach oben nicht.

Desweiteren kann es vorkommen das Zwischen den einzelnen Ebenen noch weitere Ebenen erstellt werden können:

Z.b. kommt zwischen dem Regionalleiter und dem Filialleiter auf der Linken seite ein weiterer Vertriebsleiter.

Leider kann ich jetzt noch nicht sagen in wie fern das passieren wird, aber das Tool soll diese Funktionalität von Anfang an bieten, neue Ebenen "Zwischen zuschieben"

Ich weis nicht wie man das am besten in einer MySQL datenbank löst, ich habe schon 2 Ansätze wobei mir diese nicht so gut gefallen:


1. Es gibt eine "Rechtetabelle" die wie folgt aussieht:

ID | ID_Leit | ID_Verk
----------------------
01 |   03    |   10
02 |   03    |   14
03 |   03    |   21
04 |   04    |   11
...

Kurze Erklärung: ID_Leiter ist z.B. der Regionsleiter mit der ID 3 und darf auf Verkäufer mit der ID: 10, 14, 21 und 11 gucken.

Das Problem ist, wenn ich 100 Verkäufer anlege, mit x Leitern etc, wird diese Tabelle riesig und ich denke die Performance der Abfragen rasst in den Keller...

2. Es gibt eine Rechtetabelle die mit Strings (als Array) arbeitet:

ID | ID_Leit | ID_Verk
--------------------------
01 |   03    |   10,14,21
04 |   04    |   11
...

Aber ich habe gehört das diese Art nicht gut ist und man diese Methode vermeiden soll...


Ich hoffe ich habe es verständlich ausgedrückt. Würde mich über Hilfe freuen.

[mo2402]

Könnte ein Mod den Titel ändern:
Datenbankdesign - Hierarchie über mehrere Ebenen

wäre Nett, denke der jetztige Titel könnte ggf. etwas verwirren / falsches aussagen.

[Sascha P.]

Wenn es nur um die Rechte geht, dann leg folgende Tabellen an

Usertabelle: Dort kommt natürlich sowas wie Name, Mail usw. rein, zusätzlich eine rechteID, die auf die Tabelle userrechte zeigt und der jeweilig übergeordnete "Chef".

Userrechte: Dort steht, welchen Zugangslevel der einzelne User hat und wie dieser Level heißt. Höhere Levelk dürfen auf niedrigere schauen.

Beispiel:
Userrechtetabelle:
ID 1, Betriebsleiter, Level 999
ID 2, Regionsleiter, Level 500
ID 3, Filialleiter, Level 200
ID 4, Verkäufer, Level 50
(später wird hinzugefügt
ID 5, Vertriebsleiter, Level 350

Usertablle:
UserID 1, Franz Betriebsleiter, userrechteID 1, chef = 0 (also niemand)
UserID 2, Ringo Regionsleiter, userrechteID 2, chef = 1 (also franz)
UserID 3, Franz Filialleiter, userrechteID 3, chef=2 (später dann evtl. der vertriebsleiter)

usw.

Ich hoffe, es ist klar, was ich meine und ich hoffe, es hilft dir.

[mo2402]

Also erstmal danke für die Antwort. Die idee ist gut, nur muss ich dann eine Rekursive Methode erstellen, die die untergeordneten Mitarbeiter "sucht"?

Beispiel: 
Der Regionalleiter will gucken was alle seine untergestellten Mitarbeiter so machen:

Die Methode guckt dann nach: 
Wer hat den Regionalleiter als nächsten Chef drinstehn? 
Das sind z.b. ID=5 und ID=9

Danach muss die Methode überprüfen:
Wer hat ID=5 oder ID=9  als Chef eingetragen, usw usw .....

Ich glaube das wird sehr rechenintensiv wenn ca. 100 Mitarbeiter mit diesem Tool (gleichzeitig) arbeiten.

[Sascha P.]

Ich glaube das wird sehr rechenintensiv wenn ca. 100 Mitarbeiter mit diesem Tool (gleichzeitig) arbeiten.

Glaube ich nicht, da du diese 2 Fragen mit einem Query beantworten kannst (was schneller geht wie 2 Querys).

[mo2402]

Kann man das auch mit einem Query über ggf. 4-5 Ebenen Machen? Also sozusagen: Vom Chef über Regionalleiter, über Vertrreibsleiter bis hin zum Mitarbeiter in einem Query?