Benutzer Tabelle in separaten DB

Question

Hinweis: Ich habe nicht die Absicht, dies zu implementieren, es ist eher ein Gedankenexperiment.

Angenommen, ich hätte mehrere Dienste über eine Webschnittstelle verfügbar. Mindestens zwei davon erforderten Benutzerregistrierung und einige Daten in einer Datenbank. Eine einzige Registrierung würde den Zugang zu allen Diensten ermöglichen. Wie Google (Google Mail, Google Docs usw.).

Würden sich all diese Dienste, die mit registrierten Benutzern zusammenhängen, in einer einzigen Datenbank befinden, vielleicht mit Tabellenpräfixen für welchen Dienst sie dienen?

Oder hätte jeder Dienst seine eigene Datenbank? Das einzige Plus, das ich dabei sehen kann, ist, dass Tabellennamen sauberer werden. Jedes Mal, wenn eine Benutzerinteraktion erforderlich wäre, wäre die Interaktion mit mindestens zwei verschiedenen Datenbanken erforderlich, was SQL-Abfragen unnötig kompliziert.

Würde dies darauf hindeuten, dass die "großen Jungs" nur eine einzige Datenbank verwenden und sie mit Tonnen verschiedener (und vielleicht völlig unabhängiger) Tabellen laden?

Answer 1

Wenn Sie das richtige DBMS verwenden, können Sie das Beste aus beiden Strategien haben. In PostgreSQL können Sie in einer 'Datenbank' separate Schemas haben. Der Authentifizierungsdienst würde auf ein einzelnes Schema zugreifen und den anderen Diensten einen Schlüssel zur Verfügung stellen, der als Referenz für Daten in den anderen Schemas verwendet wird. Sie können weiterhin mit der gesamten Datenbank als eine Einheit, dh befassen:

• Abfrage über Schemata ohne dblink
• speichern persönliche Daten getrennt (Schemata können getrennte Berechtigungen pro Benutzer müssen weitere Daten zu schützen)
• DBMS Fremdschlüssel Constraints verwaltet (glaube ich)
• konsistent (re Daten) Backup und

Sie diese Vorteile auf Kosten eines komplexeren DAL erhalten wiederherstellen (möglicherweise nicht von Ihrem bevorzugten DAL-Framework unterstützt) und weniger Portabilität zwischen DBMS.

Answer 2

Ich denke nicht, dass es eine gute Idee ist, mehrere Dienste von einer einzigen Datenbank abhängig zu machen. Wenn Sie einen Dienst aus einer Sicherung wiederherstellen müssen, müssen Sie alle wiederherstellen. Sie überfordern wahrscheinlich auch einen Datenbankserver. Ich würde das nur tun, wenn es wahrscheinlich ist, dass sie viele Daten zu einem späteren Zeitpunkt teilen werden.

Sie könnten auch kleinere Datenbank mit nur den gemeinsamen Benutzerdaten betrachten.

Answer 3

Ich würde in Betracht ziehen, 1 Benutzer/Rolle Repository mit einer separaten Datenbank für Dienste.

Answer 4

Es gibt immer ein Problem mit der möglichen Überlastung von Datenbanken und dem Zugriff darauf; Replikation ist eine potentiell gute Lösung.

Answer 5

Ich habe das noch nie gemacht, aber ich denke, es hängt von der Leistung ab. Wenn es keinen Overhead für separate Datenbanken gibt, könnte das die Antwort sein. Durch die Verwendung separater DBs kann die Aufteilung von DBs auf verschiedene Maschinen vereinfacht werden.

Komplexität ist auch ein Problem. Hoffentlich wäre Ihr Schema so definiert, dass Sie nicht für verschiedene Abfragen in mehrere verschiedene Datenbanken eintauchen müssen.

Answer 6

Es gibt verschiedene Strategien.

Wenn Sie zu mehreren Datenbanken (oder mehreren Servern) wechseln, werden die Dinge komplexer. Ihre Hauptbenutzerinformationen könnten sich in einer einzigen Datenbank befinden. Die einzelnen Dienste könnten in anderen Datenbanken sein. Das Problem dabei ist, dass die Datenbank die äußere Einheit der referenziellen Integrität ist, sodass Sie keine Fremdschlüssel in Datenbanken erstellen können. Eine Möglichkeit besteht darin, Änderungen an den Hauptmastertabellen zu verteilen (nur Ergänzungen und Aktualisierungen, da Löschungen aufgrund einer Fremdschlüsseleinschränkung verboten sind), um Datenbanken regelmäßig zu trennen und dann RI gegen diese Kopien von die Haupt-Master-Datenbanktabellen innerhalb der Servicedatenbanken. Dies bedeutet auch, dass die Servicedatenbanken und ihre Dienste ausgeführt werden können, während die anderen Datenbanken für die Wartung inaktiv sind. Offensichtlich ist dies eine erhöhte architektonische Komplexität für eine Verbesserung Ihrer Dienstfenster und eine reduzierte Kopplung.

Ich würde empfehlen, mit einer einzigen Datenbank zu beginnen. Wenn Ihr RDBMS dies unterstützt, würde ich Komponenten gemäß SCHEMAs organisieren, die es Ihnen erlauben würden, zumindest eine logische Trennung nach Design zu erhalten. Sie können später leichter umgestalten.

Viele Datenbanken haben Tabellen, die als unabhängig betrachtet werden können. Manchmal haben Sie in einem System mehrere Entitätsnetzwerke, die sich kaum verbinden (manchmal überhaupt nicht). Sie können in diesen Fällen auch SCHEMAS verwenden.