nicht angemeldet
Hi!
Da jeder Mitarbeiter anhand seiner Personalnummer eindeutig identifiziert werden kann, benutze ich diese gerade als Primärschlüssel(id_users) der Benutzer-Tabelle.
Ein weiser Ansatz.
Dachte ich mir auch...
(Noch weiser waere es m.E. aber einen bedeutungsfreien Primaerschluessel vom Typ uniqueidentifier zu nutzen.)
Also, nochmals zur Klärung: Die Gruppen sind nur dazu da um die Listen irgendwie unterteilen zu können. (z.B. soll jeder Geschäftszweig eine eigene Gruppe sein und seine eigenen Listen verwalten können). Die Gruppe hat also nichts mit Rechten zu tun.
Ja, das habe ich zuletzt nicht verstanden. Darum also die "n:m"-Beziehungen zwischen Liste und Gruppe.
Möchte ein Benutzer über gewisse Dinge innerhalb des Geschäftszweiges informiert werden trägt er sich nur für eine oder mehrere Listen ein und _nicht_ für eine gesamte Gruppe.
Der Nutzer traegt sich _nie_ in eine Gruppe ein, die beispielsweise eine bestimmte Liste (BTW - was bedeutet Liste hier genau?) abonniert. Stattdessen traegt er sich fuer eine Liste ein?
Es geht jetzt nur noch darum, wie ich für die einzelnen Gruppen festlegen kann wer deren ADMINISTRATOR ist oder dessen DELEGIERTE sind. Und dafür bin ich auf Lösungsvorschläge gespannt...
Also ich frage mich immer noch, warum Du nicht mit den Tabellen "Nutzer", "Berechtigungen", ggf. einer Relationentabelle "Nutzer-Berechtigungen", "Listen" und ggf. einer Relationentabelle "Brechtigungen-Listen" auskommst. Du koenntest in letztere Tabelle doch eine "IsAdmin"-Kennung einbauen?
Wie gesagt, die Gruppen werden zur Kategorisierung der Listen benutzt und haben _nichts_ mit Berechtigungen zu tun. Beispiel:
"Verkauf" (Gruppe)
+--"Verkauf von Telefonen" (Liste)
+--"Verkauf von PC's" (Liste)
Moment, das riecht nach einer Tabelle "Listenkategorien", die mit der Tabelle "Listen" in einer "1:n"-Beziehung steht, oder?
Klar, ein besserer Lösungsvorschlaf würde mir aber trotzdem weiterhelfen...?
Was denkst Du wie so ein Loesungsansatz aussieht? Wir muessen hier die Gegebenheiten der Realitaet erlaeutern, um dann diese in einem relationalen Datenbankmodell (RDBMS: 'M$ SQL Server' - programmiere ich uebrigens seit der Version 6.5) nachzubilden. Es handelt sich also weniger um einen Loesungsnansatz, der hier zu eroerten ist und den es zu finden gilt, als mehr um ein Gesamtverstehen, dessen was Du nachbilden willst (und dessen, was Du nachbilden musst, aber das waere schon ein anderes Thema ;-).
Gruss,
Ludger