Problem Defaultwerte in einer DB-Struktur unterzubringen

[Jumpy]

Hallo,

sorry für den seltsamen Titel, ich wußte nicht, wie ich es formulieren sollte:

Ich entwickele gerade eine DB-Struktur, für eine Art Benutzerverwaltung /-Steuerung für eine Anwendung.

Es gibt eine Tabelle User mit den Feldern ID, Name und Rang.
Rang ist entweder Normalo oder Admin, wobei der unterschied ist, das der Normalo nur das Programm nutzen, der Admin aber die Benutzersteuerung des Programmes verwalten kann.

Jetzt gibt es eine Tabelle "Felder" mit den Feldern ID, Text, ...
Was die Felder im Zusammenhang der Anwendung sind, ist glaub ich hier nicht wichtig.

Nun gibt es eine dritte Tabelle, die die beiden zusammenbringt: User-Felder mit den Feldern User_ID, Feld_ID, Position.
Sie steuert welche Felder für welche User sichtbar sind und (über Position) in welcher Reihenfolge.

Hier Frage1:
User_ID, Feld_ID sollen jeweils FK's auf die User bzw. Felder-Tabelle sein, zusammen aber der PK. Geht das?
Auch die Kombination aus User_ID und Position sollte eindeutig sein, müsste doch über einen weiteren Constraint gehen, oder?

Jetzt die wichtigere Frage 2:
Wenn für einen User in der Tabelle User-Felder nichts hinterlegt ist, so soll ihm eine Standardliste an Feldern angezeigt werden, die quasi für alle gilt, für die nichts anderes hinterlegt ist.
Nur wie mach ich das?

- Leg ich einen Dummy-User "Standard" an und für diesen dann in User-Felder die Standard-Felder-Liste (dabei ist der Dummy-User eigenl. unnütz und wird nur wegen der ref. Integr. gebraucht)?
- Hardcodiert im Quellcode wohl eher nicht.
- Eine separate Tabelle nur für diese Feldliste (enthält dann nur Feld_ID und Position).
- Ausserhalb der DB-Struktur, z.B. als Liste in einer INI?

Wie kann man das mit so Standart-Werten am geschicktesten/saubersten lösen?

[mkinzler]

1) Ich würde trotzdem einen künstlichen Primärschlüssel für die Zuordungsabelle verwenden. Für die Eindeutigkeit würde auch einen Unique-Index reichen
2) Z.B einen Dummy-User anlegen, mit den Standardfeldern und dieses bei allen zusätzlich Verwenden

SQL-Code:

select
    f.Text, ...
from
    zo z
        join felder f on f.id = z.Feld_ID
where
    z.USER_ID in ( 0, :USER);

[HiWieGehts]

Wie umfangreich ist die Datenbank? Müssen die angezeigten Felder pro Benutzerklasse (Normalo, Admin, Standard) DB-gesteuert veränderbar sein? Wenn nein und nicht zu viele Datenfelder würde ich für jede Benutzerklasse eigene Forms bauen und die abhängig der Benutzerklasse anzeigen. Tabelle 3 wäre damit nicht erforderlich.
Wenn das für die geforderte Sicherheit nicht ausreicht, sollte auf jeden Fall ein Berechtigungskonzept auf DB-Ebene eingerichtet werden.

[DeddyH]

Zitat:

Zitat von HiWieGehts (Beitrag 1144609)

Wenn das für die geforderte Sicherheit nicht ausreicht, sollte auf jeden Fall ein Berechtigungskonzept auf DB-Ebene eingerichtet werden.

Ich bin auch der Meinung, dass das über Rollen evtl. schöner zu handlen sein müsste. Aber das ist nur ein erster Gedanke.

[jobo]

Zum Modell:
Angenommen Postion und Rang sind jeweils Key bzw zugehöriger Foreign Key.
Reicht es nicht aus, die Relation auf Rang/Position zwischen User und Feldliste zu setzen. Jedenfalls scheint mir die Kombi FeldID, Position in der Zwischentabelle etwas redundant. (Zumindest wenn Rang eigentlich für Feldsichtbarkeit usw. steht)

- Rang erweitern auf 3. Wert: Default (Um die Definition dieser Variante kommst Du eh nicht rum)
- Feld Postion mit in die Feldtabelle aufnehmen. Alle Definitionen (Sichtbarkeit, .. ) werden direkt je Rang vorgenommen.
- Ein User wird nur über die Position /Rang mit den Definitionen gejoined.

Letztlich wird hier ja der Rang wie eine (DB-)Rolle gehandhabt. Eine DB-Rolle liefert allerdings nur bei Oracle Enterprise auch Rechte auf Feldebene. Weiß nicht, ob das Enterprise das enthält oder nur Voraussetzung ist.

[Jumpy]

Ich fürchte ich hab für Verwirrung gesorgt und versuche daher nochmal es etwas anders zu schildern:

In der Tabelle User. Das Feld Rang: Hat eigentlich nix zu sagen. Es legt nur fest, wer User und wer Admin ist. User können das Programm nutzen. Admins es auch einrichten. Welchen Rang man hat, hat also nix mit den Feldern (und deren Sichtbarkeit) usw. zu tun. Und auch nicht mit DB-Rechten. Nur was man im Programm darf und was nicht.

In der Tabelle User-Felder. Das Feld Position. Steht für Anzeigeposition. In User-Felder steht ja, welche Felder ein User sehen darf. (Anzeige-)Position gibt nun nur an, in welcher Reihenfolge.

Die "Felder" die dem User ggf. angezeigt werden, haben trotz des Namens nix mit Tabellenfeldern zu tun. D.h. da kann man auch nicht über DB-Rollen oder so was machen.

Hoffe, dass es so klarer ist. Es wäre ggf. denkbar User-Klassen anzulegen, und die Felder-Sichtbarkeit von der Klasse abhängig zu machen. Der User wird dann einer Klasse zugeteilt und übernimmt deren Feldersichtbarkeit. Das enthielte dann vllt. auch die Option eine Standardklasse anzulegen und einem neu angelegten User diese Klasse als Default (per Constraint in der DB) mitzugeben.....
....Je mehr ich darüber bei schreiben nachsinne, kommt es mir vor, als ob das eine Lösung sein könnte.
Einziger Nachteil: Es kann bei uns ggf. sehr individuell werden, d.h. es würde Klassen geben, die alleine nur für einen User angelegt werden.

[jobo]

Das sieht tatsächlich etwas anders aus, als gedacht.

Deine Pläne zur Schlüsselung/Eindeutigkeit kannst Du so oder so umsetzen.
Mit dem Modell zu Sichtbarkeitslassen landest Du im Grunde bei logischen Rollen.
Hier würde ich etwas Gehirnschmalz reinstecken und planen, wie sich diese Rollen untereinander verhalten. Mehrfachzuordnung, Addition, Subtraktion, Überlappung, usw.
Auch wenn es filigran wird, erst wenn der letzte User seine eigene Rolle hat, erreichst du beim Pflegeaufwand den Level, den Du auf Userebene von Anfang an hast (ausgenommen der Verwendung einer Defaultrolle, damit bist Du aber in der technischen Umsetzung schon bei der Rolle und damit redundant)

[p80286]

Zitat:

Zitat von jobo (Beitrag 1144646)

Hier würde ich etwas Gehirnschmalz reinstecken und planen, wie sich diese Rollen untereinander verhalten. Mehrfachzuordnung, Addition, Subtraktion, Überlappung, usw.

"Planen" ist natürlich gut, aber wenn Individualität möglich ist, dann haben 10 phys. Benutzer 20 logische Rollen.

Zitat:

Zitat von jobo (Beitrag 1144646)

Auch wenn es filigran wird, erst wenn der letzte User seine eigene Rolle hat, erreichst du beim Pflegeaufwand den Level, den Du auf Userebene von Anfang an hast (ausgenommen der Verwendung einer Defaultrolle, damit bist Du aber in der technischen Umsetzung schon bei der Rolle und damit redundant)

?? Wie bitte ??
Liest sich wie: je komplexer desto besser!(?)

Gruß
K-H