Datenbank Design

[Spin]

Hallo liebe Community,

ich habe da mal folgende Frage bzw. folgendes Problem:

Ich habe Customer, Staff und Admins. Alle 3 Gruppen haben verschiedene Access Rechte , definierte Rollen sind in der Tabelle : role vorhanden (Admin,Staff, Member)

Ich habe eine Anwendung in der sie sich einloggen sollen und entsprechend ihrer Rollen sehen sie mehr oder weniger. Dazu habe ich folgende Ansätze um den Login zu handeln:

1. Lösung:

Ein Login für alle :

Ich habe eine Tabelle user : (user_id, user_pw , user_pw_salt , user_role)
Ich habe eine Tabelle customer : (customer_id ....)
Ich habe eine Tabelle staff (staff_id ...)
Ich habe eine Tabelle admin (admin_id ...)

Tabelle user (user_id) : FK : customer_id, admin_id, staff_id

Der PK von user_id zeigt auf den PK von customer_id, admin_id und staff_id

Damit ist der user jetzt entweder in der Tabelle customer, in der Tabelle staff oder in der Tabelle admin zu finden.

Der Benutzer loggt sich ein und ich frage in der user Tabelle ab. Anschließend bekomme ich die Rolle und weiss in welcher Tabelle ich dann mit meiner id fragen muss.

Ich habe also : Select an table user + Select an table customer,staff,admin



2. Lösung

Ich habe eine Tabelle customer : (customer_id user_pw , user_pw_salt , user_role)
Ich habe eine Tabelle staff (staff_id user_pw , user_pw_salt , user_role)
Ich habe eine Tabelle admin (admin_id user_pw , user_pw_salt , user_role)


Weiterhin habe ich dann zwei Logins. Einen für die Kunden und einen für admin,staff.
Kundenlogin --> select an customer

Adminlogin --> select an admin , wenn da nicht , select an admin

Hier kann auch ein customer ein Admin sein ... was in der oberen Lsg nicht geht.

--

Was ist denn jetzt sinnvoller? Ich habe sicherlich viele Vorteile und Nachteile vergessen... aber für was würdet ihr euch entscheiden?

Muss noch viel Erfahrung sammeln ....:rtfm:

vielen dank!!

 

[XHelp]

Was ist denn jetzt sinnvoller?

Keins davon :bahnhof:
warum nicht:

users: id, login, password, role

und das war's. Da hast du ja schon direkt die Rolle des Benutzers und kannst anhand des Eintragen entscheidungen im Programm treffen.
Was soll die Aufspaltung in 10000 Tabellen bringen?

 

[Spin]

Du meinst also das eine user Tabelle reicht und ich dann anhand der Rolle und der Id in einer anderen Tabelle neu nachfrage.

Stell dir jetzt vor ich möchte einen neuen Benutzer anlegen. Der Benutzer hat noch ganz viele Daten : Name, PLZ , Ort usw.

Das heißt ich mache ein INSERT in die user Tabelle und ich mache ein INSERT in Benutzertabelle.
Analog zu Admin und Staff Tabelle.

Bei der zweiten Lösung müsste ich halt nur einen Insert machen. Genau in der Tabelle in der ich einen neuen Datensatz anlegen möchte.


Aber dank schon mal.

Eine Tabelle user finde ich gut, und da fällt mir ein, dass ich selbst mit einer Tabelle user zwei Logins basteln könnte

Szenario:

Was mache ich wenn ein Admin zwei Rollen hat ? System-Admin und Management-Admin, aber nicht Access-Admin.
(lediglich Besipiele)

Hat dann ein Datensatz zwei role_id 's.?

Oder nimm ich dann eine user_role_rel Table? Ja so müsste es klappen.

user role
1 1
1 2
2 1

Many to Many.

Also eine User Tabelle und dann mithilfe der ID und der ROLLE eine weitere Tabelle anfragen um die entsprechenden Daten zu bekommen?


--
Andere Frage:

Was passiert wenn ich eine Tabelle habe mit 5 ForeignKeys und die Tabellen haben nochmals Foreignkeys.

Kann ich Joins schachteln? Wenn ja hat einer nen Beispiel?

Danke .)

 

[XHelp]

Wenn du wirklich mehrfachzuweisung machen willst, dann verzichtest du eben auf "role"-Eintrag des user-Tabelle. Bei deiner Struktur musst du dir noch gedanken machen, was passiert, wenn die Rollen entgegengesetzte Merkmalle haben? "Schreiben erlaubt" vs "Schreiben verboten": welches nimmst du da?

Was du mit der anderen Frage meinst, verstehe ich nicht wirklich. Aber so alles in einem hört es sich nach einer ziemlich verkorksten Struktur an.

 

[oopexpert]

Berechtigungen sind ein dreiwertiges Tupel aus:

1. Wer (Benutzer / Benutzergruppe)
2. darf was (Recht / Rolle)
3. mit was machen (Resource)

Das Maß der Flexibilität muss hier entschieden werden. In einer schon sehr großen Ausbaustufe würde man folgende Tabellen haben:
- Benutzer
- Benutzergruppe (gruppiert Benutzer)
- Recht
- Rolle (gruppiert Rechte)
- Relationstabellen zwischen Ressourcen, Benutzer- und Benutzergruppen, Rollen und Rechte

In Deinem Fall kann man sicherlich einige Dinge zusammenfassen.

Üblicherweise entscheidet man sich entweder für Rollen-Konzept (Oracle DB) oder Gruppen-Konzept (Microsoft Active Directory). Ich kenne kein System, was beide Konzepte verfolgt. Ich gehe davon aus, dass Du mit Rollen arbeiten möchtest. Deshalb wird die Tabelle "Benutzergruppe" nicht benötigt. Die Alternative hat eine höhere Komplexität, denn man kann dann weiterdesignen und es tauchen folgende Fragen auf: Gruppen in Gruppen? Was ist mit Zyklen in der Gruppenstruktur?

Wenn Du keine flexible Gruppierung von Rechten zu Rollen benötigst und die von Dir definierten Rollen eine Menge von fixierten Rechten darstellen, dann ist die Rechte-Tabelle überflüssig. Aus Deinen Ausführungen würde ich ableiten, dass Du nicht explizit jedes Recht verwalten möchtest, sondern schon Rechtegruppen (Rollen) definiert hast. Die Alternative würde eine Menge weiterer Fragen aufwerfen, wie z.B. können Rollen in Rollen existieren? Zyklenbehandlung? Sollen Rechte positiv und/oder negativ definiert werden? Wie sieht die Priorisierung bei sich widersprechenden Rechten aus (siehe XHelp)?

Sind zusätzlich zu den Rollen auch schon die Resourcen implizit festgelegt, dann fällt auch die Ressourcentabelle weg. (Ein Administrator ist grundsätzlich für alle Bereiche Administrator vs. Ein Administrator ist nur für bestimmte Bereiche Administrator). Hier entscheidet sich, ob man funktionsbezogene Berechtigungen oder Objektberechtigungen vergeben möchte. Hier kenne ich Deine Anforderungen nicht.

Ich habe hier nur einen Teil dessen, was man an Anforderungen an ein Berechtigungssystem stellen kann, angesprochen und jede zusätzliche Anforderung kann das Modell verändern. Deshalb stimme ich XHelp zu, die Anforderungen nochmal gegen das Modell zu prüfen.

 

[Spin]

Moin und vielen Dank für eure Erklärungen.

Ich habe mich vielleicht ein wenig uneindeutig ausgedrückt und möchte dass nochmal nachholen.
Und zwar geht es um eine Anwendung die Beispielsweise das Modul News besitzt.

Modul: News

News anlegen
News löschen
News ändern
News runterladen
News ins Archiv schieben
News als E-Mail versenden
News Vorschau
usw.

Ich habe also eine Reihe an Funktionen, die nur bestimme Leute machen dürfen.

Daher habe ich eine Tabelle: role :

role
1 Admin
2 Staff
3 User

Nun möchte ich gerne das der Staff News anlegen und News ändern darf, aber nicht News löschen oder als E-Mail versenden.
Diese Problematik beschreibt die Benutzerrollen, aber nicht das Konzept, wie ich die User alle insgesamt verwalte.

Und zwar bestehen meine User aus : Customer, Staff und Amdin.

Die Idee ist es jetzt eine komplette User Tabelle zu erstellen, wo alle User ein pw und eine role haben.
Weiter habe ich eine Tabelle: Customer , Tabelle: Staff, Tabelle: Admin.
In diesen Tabellen sind dann mehrer Informationen zu den jeweiligen Entities vorhanden.

XHelp hatte ja schon vorgeschlagen, mit der user_id und der role dann ein select an Customer, Staff oder Admin zu machen.

Vorschlag zwei war halt : Keine User Tabelle , sondern gleich Tabelle: Customer, Tabelle: Staff und Tabelle : Admin.

Entsprechend zwei Logins für einen Admin bereich und einen Userbereich.



--
Ich habe mich aber jetzt für Lsg. 1 entschieden und mit hilfe eines Logins. Ich frage die Datenbank an und bekomme eine Role zurück. Anhand der rolle entscheide ich in welchen Bereich der User weitergeleitet wird.

Aso : ein Beispiel für die detailierte Benutzerverwaltung wäre toll
Vielen Dank fürs Lesen und kommentieren

 

[XHelp]

XHelp hatte ja schon vorgeschlagen, mit der user_id und der role dann ein select an Customer, Staff oder Admin zu machen.

Habe ich gar nicht. Bei meinem Vorschlag gibt es keine Tabellen Customer, Staff, WasAuchImmer, weil die einfach nun mal kein Sinn ergeben.