Benutzer und Benutzerprofil in verschiedenen Tabellen behalten?

Ich habe in einigen Projekten gesehen, dass Entwickler es vorziehen, wichtige Benutzerinformationen in einer Tabelle (E-Mail / Login, Kennwort-Hash, Bildschirmname) und den Rest des nicht wichtigen Benutzerprofils in einer anderen zu speichern (Erstellungsdatum, Land usw.). Mit nicht wesentlich meine ich, dass diese Daten nur gelegentlich benötigt werden. Der offensichtliche Vorteil ist, dass es offensichtlich gut ist, wenn Sie ORM verwenden, weniger Felder abzufragen. Sie können jedoch auch zwei Entitäten derselben Tabelle zuordnen. Auf diese Weise können Sie nicht mehr Dinge abfragen, die Sie nicht benötigen (und sind dabei bequemer). Kennt jemand einen anderen Vorteil, wenn man diese Dinge in zwei Tabellen aufbewahrt?

Dies hängt von der Größe und den Anforderungen Ihres Projekts ab.

Ich sehe eine Möglichkeit, wie Daten über Benutzer in zwei Gruppen mit unterschiedlichen Zwecken und Anforderungen aufgeteilt werden können:

• Identitätsdaten: Benutzername, Passwort-Hash, E-Mail-Adresse, letzte Anmeldezeit usw.
• Benutzerprofildaten, darunter Benutzervorgaben, neueste Aktivitäten, Statusaktualisierungen usw.

Beachten Sie, dass es einige Attribute zu dem Benutzer gibt, die in eine der beiden Kategorien fallen können (z. B. das Geburtsdatum des Benutzers). Der Unterschied zwischen diesen beiden Sätzen besteht jedoch darin, dass der erste streng kontrolliert wird und nur durch bestimmte Workflows geändert werden kann. Wenn Sie beispielsweise ein Kennwort ändern, müssen Sie möglicherweise ein vorhandenes Kennwort angeben. Wenn Sie die E-Mail ändern, müssen Sie möglicherweise die E-Mail-Adresse überprüfen. Diese Option wird verwendet, wenn der Benutzer das Kennwort vergisst.

Einstellungen erfordern keine solchen ACLs und können theoretisch vom Benutzer oder einer anderen Anwendung geändert werden, solange der Benutzer dem zustimmt. Der Einsatz ist gering, wenn eine Anwendung böswillig oder aufgrund eines Fehlers die Daten beschädigt oder versucht, sie zu ändern (vorausgesetzt, es werden andere Sicherheitsmaßnahmen ergriffen). Es wäre jedoch in der Regel katastrophal, wenn der Benutzername, das Kennwort oder die E-Mail-Adresse geändert werden könnten da sie entweder verwendet werden können, um die Identität des Benutzers anzunehmen oder den Dienst zu verweigern oder Supportkosten usw. für den Administrator zu verursachen.

Daher werden die Daten normalerweise in zwei Arten von Systemen gespeichert:

• Identitätsdaten werden normalerweise in einem Verzeichnis oder einer IAM-Lösung gespeichert.
• Die Präferenzdaten werden in einer Datenbank gespeichert.

In der Praxis verstoßen die Benutzer jedoch gegen diese Regeln und verwenden die eine oder andere (z. B. SQL Server hinter dem ASP.NET-Mitgliedschaftsanbieter).

Wenn die Identitätsdaten größer werden oder die Organisation, die sie verwendet, größer wird, treten verschiedene Arten von Problemen auf. Im Fall von Verzeichnissen wird beispielsweise versucht, die Kennwortänderungen sofort auf alle Server in einer Umgebung mit mehreren Servern zu replizieren. Benutzerpräferenzen erfordern jedoch nur eine eventuelle Konsistenz. (Zu Ihrer Information: Beide sind unterschiedliche Optimierungen des CAPS-Theorems.)

Schließlich stellen Verzeichnisse (insbesondere die Online- / Cloud-Verzeichnisse) auch Zugriffstoken für andere Ressourcen mithilfe von Protokollen wie OAUTH aus (z. B. Facebook, Google, Microsoft-Konto, ADFS), während eine Datenbank dies nicht benötigt. Eine Datenbank unterstützt sehr komplexe Verknüpfungen und Abfragestrukturen, die das Verzeichnis nicht benötigt.

Für weitere Details helfen ein paar Suchanfragen nach Identitätsverzeichnis und Datenbank.

Letztendlich kommt es darauf an, wie Ihre Szenarien aussehen und wie sie in Zukunft aussehen werden, einschließlich der Integration mit Drittanbietern (und was diese verwenden). Wenn es sich um ein in sich geschlossenes Projekt handelt und Sie sicher sind, dass Sie die Benutzeridentitätsdaten sichern und sich korrekt authentifizieren können, können Sie sich für eine Datenbank entscheiden. Andernfalls könnte es sich lohnen, ein Identitätsverzeichnis zu untersuchen.

Wenn Sie sich für DB, IMO, entscheiden, wird die Zugriffskontrolle für Benutzer und Anwendungen letztendlich durch die Verwendung von einer DB gegenüber zwei DBs eingeschränkt.

Es gibt mindestens drei Fälle, in denen eine Personentabelle für grundlegende Attribute und eine zweite Tabelle für andere Attribute mit einer Eins-zu-Eins-Beziehung wünschenswert sind:

• BLOB-Daten wie ein Bild. Eine separate Tabelle ermöglicht es, Daten aus Leistungsgründen separat zu speichern, beispielsweise in einem separaten Tabellenbereich.
• Daten, die nicht für alle gelten oder die nur für eine Person gelten, die eine bestimmte Rolle spielt. Stellen Sie sich das als Spalten vor, die in vielen Zeilen null wären, wenn sie Teil der Haupttabelle wären. In der Datenbank einer Klinik können Sie eine Personentabelle, eine Patiententabelle und eine Medizintabelle haben, in der ersten würden Sie grundlegende Attribute haben, in der zweiten nur Attribute, die relevant sind, wenn die Person ein Patient wie Versicherungsschutz ist In der dritten Tabelle (wenn die Person ein Arzt ist) können Sie die medizinischen Fach- und sonstigen Daten finden, die nur für medizinisches Personal gelten. Offensichtlich kann ein Sanitäter ein Patient sein.
• Eine Tabelle, die eine Beziehung zu einer Entität in einem fernen System herstellt. In diesem Fall erstellt die Tabelle aus Gründen der Interoperabilität eine Äquivalenz zwischen eindeutigen Bezeichnern in einer separaten Datenbank.

Ich denke, der Fall, den Sie aufdecken, passt in den zweiten Fall.

Mein Hauptgrund, sie getrennt zu halten, ist zu versuchen, das zu vermeiden, was in der objektorientierten Programmierung als "Gottklasse" bekannt ist. ORMs verknüpfen Tabellen und Felder mit Klassen und Attributen, sodass sie auch für die SQL-Ebene relevant werden (auch ohne ORM gibt es im Allgemeinen ein ähnliches Prinzip).

Die Benutzerklasse (und nach Zuordnung die Benutzertabelle) ist häufig die Tabelle, die zur Gottklasse mit Hunderten von Attributen / Feldern, Dutzenden oder Hunderten von Methoden und einer Klassendefinition (für die Methoden) von über 1000 Zeilen wird. Ich habe alles gesehen. Mehr als einmal.

Die Trennung von Benutzern versucht also, dies zu beheben. Möglicherweise gibt es Personen, Benutzer, Konten und die Trennung von Bedenken scheint etwas künstlich, aber es ist zu versuchen, Komplexität zu vermeiden und sicherzustellen, dass jedes Objekt nur einen Aspekt der Daten betrifft.