2016-05-05 11 views
0

Ich habe 3 verschiedene Arten von Benutzern:Database acl Login Design

-Client -Employee -Admin

Und ich will jetzt nur 1 Login-Seite, alle von ihnen zu identifizieren.

Mein Beispiel: Login-Tabelle mit den Feldern:

Benutzername Passwort id clientid adminid Employeeid Rolle

Client-Tabelle mit den Feldern:

Name Alter Adresse id.

Und jetzt möchte ich einen Client mit dem Benutzernamen hinzufügen: admin. Ich kann ihn nicht hinzufügen, weil ein Benutzername wie dieser existiert (mit der Rolle admin). Client-Tabelle ist nur für zusätzliche Informationen. Die beste Lösung sollte 1 Tabelle mit allen Informationen sein, aber was ist mit Feldern, die ich nicht brauche. Beispiel: Ich brauche kein Feldgehalt (sollte nullfähig sein?), Wenn ich Kundendaten drucke, und sagen wir, dass ich mehr als 50 Felder nur über Mitarbeiterinformationen habe. Ich denke, mein aktuelles Datenbankdesign ist schlecht. Was soll ich machen?

Antwort

0

Es gibt zwei Ansätze zum Nachdenken.

Man macht einen Unterschied zwischen einer Person und den Rollen, die sie einnehmen kann. Dies bedeutet eine 1: 1, n Beziehung zwischen Person und Rolle. Alle Attribute, die die Person beschreiben, wie Name, Benutzer-ID, gehashtes Passwort, gehen zu der Person, die rollenspezifischen Attribute wie Gehalt gehen zur Rolle. Dies ist sehr vielseitig, wenn es wirklich passiert, dass eine Person mehrere Rollen übernimmt. Ich bin mir nicht sicher über Client und Mitarbeiter, aber Admin und Mitarbeiter klingt, als könnte es von der gleichen Person genommen werden.

Wenn das nicht der Fall ist, d. H. Wenn jede Person entweder Kunde, Mitarbeiter oder Administrator ist, aber nie mehr als eine dieser Personen, wäre dies ein Overkill. Dann haben Sie logisch eine Erbschaftssituation, wobei c, e und a besondere Fälle von Person sind. Es gibt mehr als eine Technik, um dies in einer relationalen Datenbank zu implementieren, die Vererbung nicht unterstützt. Am einfachsten ist die Hierarchie der Tabellen pro Klasse, was bedeutet, dass alle Attribute der allgemeinen Person und der Spezialisierungen in eine Tabelle geschrieben werden und sie, wenn nötig, null sein müssen. Bei vielen Attributen, die für jede Spezialisierung spezifisch sind, sind auch separate Tabellen möglich.

Übrigens hat das alles nichts damit zu tun, ob Sie nur eine Login-Seite für alle haben wollen. Selbst wenn Sie mehr als eine Tabelle haben, können Sie eine Ansicht trotzdem als eine Vereinigung von ihnen definieren, die die Benutzernamen und Hash-Passwörter und möglicherweise einige allgemeinere Daten enthält.

Übrigens war meine Bemerkung im ersten Abschnitt über die Benutzerberechtigungsnachweise, die Teil der Personeneinheit sind, eine Vereinfachung. Ein Benutzer zu sein kann auch eine Rolle sein, die nicht einmal notwendigerweise an eine Person gebunden ist. Stellen Sie sich einen automatischen Job vor, der auf Ihre Datenbank zugreifen muss. Es ist auch ein Benutzer, dem bestimmte Privilegien zugewiesen werden können, aber es ist keine Person. Ich weiß nicht, ob Ihre Anforderungen es klug machen, diesen Unterschied zu machen.