Benutzer, Kunden, - admin-Konto in 3 verschiedenen Tabellen?

In meinem web-Anwendung habe ich drei verschiedene Arten von Konten.

  • Nutzer: für die Nutzung der web-Anwendung kostenlos
  • Kunden: für Werbung und bekommen ein Firmenlogo
  • Admin: für die Bearbeitung und das löschen von Sachen

Sollten all diese drei werden in separaten Tabellen oder in einem mit einer Spalte namens "account_type" wo kann ich markieren Sie es als Nutzer, Kunde oder Admin?

Was sind die vor-und Nachteile für beide? Gibt es ein best practice für diese?

Dank

  • Ich denke, es wäre nützlich, zu bleiben, wie die use cases beziehen sich auf andere Dinge in Ihrem Datenmodell. I. e. was ist die Verbindung zwischen Kunden und Bilder, User - /Admin-Zugang.
  • Ich würde sagen, eine Tabelle, aber wenn es gibt eine Menge verschiedener Attribute für jede Rolle, sollten Sie sich Gedanken über verschiedene Tabellen. Sie können markieren Sie die Benutzer mit einer id/enum, nennen wir es mal-Rolle. Rolle=1 wäre ein Benutzer, Rolle=2 wäre ein Kunde und Rolle=3 wäre ein admin. So können Sie leicht erweitern Sie Ihre Rollen mit einer foreign key-Konstrukt (wie David Stratton sagte).
InformationsquelleAutor never_had_a_name | 2010-08-18
  1. 16

    Im Allgemeinen eine person werden kann, Benutzer -, Kunden-und admin-also ich würde beginnen mit einer Person Tabelle mit Spalten IsCustomer, IsUser, IsAdmin. Später (für schnelle Suche) können Sie sich entscheiden, fügen Sie separate Tabellen Admin, Customers, Users mit FK auf die Person Tabelle.

    EDIT:

    Einen typischen Fall:

    • 5 Millionen Nutzer
    • 1000 Kunden
    • 10 admins

    Im Allgemeinen, mit separaten Tabellen für die Kunden und die admins sollten beschleunigt werden, jeder admin/kundenbezogene Abfrage.

    • Manchmal, Nutzer und Kunden haben unterschiedliche Eigenschaften, so dass Sie brauchen, um split in 2 Tabellen, anstatt optionalen Spalten in derselben Tabelle.
    InformationsquelleAutor Damir Sudarevic
  2. 8

    Wenn ein user kann nur einen geben, Sie wären besser dran mit einem Tisch und ein bit-Feld für IsAdministrator, etc.

    Wenn ein Benutzer mehr als ein Konto geben, Sie sollten dann eine andere Tabelle mit einer foreign key -,

    Beispiel-Struktur (Daten sypes sind SQL Server und schlug nur)

    Benutzer-Tabelle

    • UserID - int
    • Username - varchar(25)
    • Passwort varchar(25)
    • Vorname - varchar(50) etc...

    Der Rollen-Tabelle

    • RoleId - int
    • Rolle Beschreibung varchar(25)

    User_Roles Tabelle

    • UserId - int (mit einem foregin key auf die Tabelle Benutzer)
    • RoleId int (Fremdschlüssel auf die Rollen-Tabelle)
    • Ich denke, ich bekomme Sie. Eine Tabelle für die basic-Informationen, die von Ihnen geteilt werden, dann 3 verschiedene Tabellen für jede von Ihnen mit spezifischen Informationen, dann habe ich link zu, der Sie mit einer foreign_key in der basic Tabelle rechts?
    • Ja, du schon wusste, dass es,
    • Ich dachte, du meintest eine Tabelle für Administratoren und eine für custmers mit alle sich wiederholenden Informationen. Lese ich es falsch, habe ich nicht?
    InformationsquelleAutor David
  3. 2

    Vor-und Nachteile variieren basierend auf der Größe und Komplexität Ihres Systems.

    Ich würde brechen Sie in Benutzer, Rollen, UserResources

    Benutzer (würde, definieren Sie grundlegende Informationen)

    Benutzerrollen

    • FK->RoleType

    Role_Type (Benutzer, admin Kunde, möglicherweise Berechtigungen oder Sie brechen könnte diese weiter).

    UserResources (Medien -)

    • FK->Benutzer
    InformationsquelleAutor Nix
Schreibe einen Kommentar