Ist es eine gute Idee, Synonyme zu verwenden, um das Erstellen einer doppelten Tabelle zu vermeiden?

Wir haben 3 Kopien der exakt gleichen Datenbank. Alle 3 Datenbanken haben eine UsersTabelle, und in allen 3 Datenbanken ist immer ein Benutzer mit genau den gleichen Einstellungen vorhanden. Jedes Mal, wenn wir einen Benutzer hinzufügen oder bearbeiten möchten, müssen wir 3 Datenbanken aktualisieren.

Wäre es eine bessere Idee, die UsersTabelle aus den Datenbanken 2 und 3 zu löschen und durch eine zu ersetzen Synonym, die auf die Datenbank 1 verweist?

Hier sind die Vor- und Nachteile, die mir einfallen:

Vorteile

• Einfachere Wartung. Kann Benutzer an einem Ort anstatt an 3 aktualisieren
• Benutzer-IDs stimmen zwischen Datenbanken überein (Wichtig, da viele Add-On-Apps auf UserId basieren)

Nachteile

• Denken Sie nicht, dass dies ein Standardverfahren ist, es könnte also verwirrend sein
• Benutzer müssten identische Einstellungen zwischen Datenbanken haben
• (Aus der Antwort von gbn weiter unten) Wenn die Datenbank 1 jemals ausfällt , sind auch die Datenbanken 2 und 3 nicht verfügbar. Außerdem besteht das potenzielle Problem, dass die Daten im Falle einer Wiederherstellung inkonsistent sind

Dies ist eine Option, die ich für einige verschiedene Tabellen in Betracht ziehe, die Einstellungen enthalten, die zwischen den Datenbanken und nicht nur der UsersTabelle identisch sind . In diesem Beispiel verwende ich Users, da es leicht zu verstehen ist.

Warum haben Sie 3 Datenbanken mit den gleichen Benutzern?

Was passiert, wenn eine Datenbank jetzt ausfällt?

Ich stelle diese Fragen, weil die Nachteile der Benutzerquellendatenbank, die die Verwendung der anderen beiden Datenbanken verhindern, möglicherweise nicht so groß sind, wie es sich anhört.

Wenn eine Datenbank jetzt ausfällt, treten bereits Konsistenzprobleme auf, wenn Benutzer in diesem Zeitraum in den anderen beiden DBs geändert werden. Ich denke nicht, dass wir den besten Rat geben können, ohne mehr Kontext.

Im Moment würde ich eine vierte Datenbank für Benutzer erstellen, Änderungen nur dort vornehmen und die anderen Datenbanken synchronisieren. Sie sind bereits verteilt-denormalisiert, indem Sie im Wesentlichen dieselben Daten an drei Stellen ändern, und haben wahrscheinlich bereits Konsistenzprobleme. Wenn Fehlertoleranz wichtig ist, gibt dieses Schema dies bei der Lösung des Mehrfacheintragungsproblems immer noch an.

Ich denke, dass es eine gute Strategie ist, diese vierte Datenbank nur für Benutzer / Einstellungen zu haben, anstatt eine Ihrer vorhandenen zu verwenden, da es weniger wahrscheinlich ist, dass sie ausfällt, da sie nicht an andere Ressourcen gebunden ist oder stark genutzt wird. Ich sehe jetzt, dass du gesagt hast, dass du das nicht kannst, aber ich weiß nicht warum. Unterstützen die Anwendungen in der Hauptdatenbank die direkte Bearbeitung durch Benutzer oder ist die Bearbeitung durch Benutzer eine völlig separate Funktion, auf die an anderer Stelle verwiesen werden kann?

Richtig, mit dieser Idee der "kanonischen Benutzertabelle" - ob Sie Synonyme verwenden oder die Daten synchronisieren - können Sie keine Benutzer während einer heruntergefahrenen Benutzer-DB ändern, aber das scheint mir in Ordnung zu sein. Beheben Sie das Problem und bringen Sie es zur Sprache! Eine Quelle, ein Ort zum Bearbeiten, eine Sache zum Reparieren, wenn sie kaputt ist. Bei der Synchronisierung verfügen alle anderen Datenbanken über temporäre Kopien, aus denen sie arbeiten können, aber keine Bearbeitung. Das Minimieren der Datenduplizierung zwischen Systemen ist ein großes und nützliches Ziel. Es ist ein ernstes Problem, dieselben Daten an drei Stellen einzugeben. Tun Sie also alles, um dies zu beseitigen.

Wenn Ihre Benutzer-IDs in all Ihren Anwendungen unterschiedlich sind, sollten Sie ernsthaft über eine geplante Ausfallzeit für die beiden neuen Datenbanken nachdenken, um sie mit der Hauptdatenbank zu synchronisieren. Wenn Sie Ideen benötigen, stellen Sie eine separate Frage darüber, wie dies zu erreichen ist, was schwierig, aber nicht wirklich so schwer ist).

Wenn Sie Ihre Geschäftsanforderungen analysieren und feststellen, dass die Hauptdatenbank die Benutzerdaten enthalten muss, die in Ordnung sind, verwenden Sie sie dennoch als kanonisch. Wählen Sie dann zwischen Synonymen oder Synchronisierung, um zu ermitteln, wie sich ungeplante Ausfallzeiten auf alle Datenbanken auswirken.

Ein weiterer Nachteil bei der Verwendung von Synonymen ist, dass Sie nicht mehr in der Lage sind, den Benutzern in jeder Datenbank die richtigen FKs zuzuweisen.

Es fehlt ein "Con"

Beim Wiederherstellen ist es möglich, dass Ihr Benutzer nicht in der Zieldatenbank (der Synonymdatenbank) vorhanden ist. Angenommen, es ist beschädigt, und Sie müssen von einem Backup wiederherstellen.

Das heißt, die Verwendung von Synonymen setzt datenbankübergreifende referenzielle Integrität voraus, die im wirklichen Leben nicht vorkommen kann.

Eine weitere Konsequenz wären nicht übereinstimmende Benutzer-IDs, wenn Sie versuchen, diese wiederherzustellen. (durch Hinzufügen des Benutzers nach der Wiederherstellung). Dies sollte jedoch aufgrund der erwähnten datenbankübergreifenden referenziellen Integrität ohnehin nie angenommen werden.

Also tu es nicht ...

Eine verwandte Antwort auf dba.se: Entscheidungskriterien für die Verwendung eines Nicht-DBO-Schemas im Vergleich zu einer neuen Datenbank zur "datenbankübergreifenden referenziellen Integrität" nach Wiederherstellungen

Abhängig von Ihrer Datenbankplattform besteht eine andere Möglichkeit darin, die Tabellen in den Datenbanken 2 und 3 zu löschen und durch materialisierte Ansichten der Tabelle in Datenbank 1 zu ersetzen .

Vorteile

• Einfachere Wartung (der Daten)
• Passende IDs
• Ausfälle wirken sich nicht auf andere Datenbanken aus (zumindest nicht, bis Änderungen vorgenommen werden müssen)
• Zum Wiederherstellen der Tabelle kann eine beliebige Datenbank verwendet werden.

Nachteile

• Die Daten sind nur so aktuell wie Ihr Aktualisierungszeitplan.
• Wenn sich die Tabellendefinition ändert, müssen möglicherweise auch die materialisierten Ansichten geändert werden.

Beachten Sie auch, dass dies je nach Häufigkeit der Suchvorgänge, Aktualisierungshäufigkeit und Häufigkeit der Datenänderungen möglicherweise mehr Last verursacht als eine Synonymlösung.

Update: Der Kommentar von FrustratedWithFormsDesigner ist im Wesentlichen eine materialisierte Ansicht für Plattformen, die keine materialisierten Ansichten ausführen können. Mithilfe eines Skripts können die Tabellen regelmäßig synchronisiert werden. Wenn eine Datenbank als Master festgelegt ist, können alle Skripte ihre Änderungen basierend auf dieser Datenbank vornehmen. Dies hätte alle Vor- und Nachteile einer materialisierten Sichtweise; Die eingebaute Funktionalität konnte einfach nicht genutzt werden.

Ich würde eine 4. DB erstellen, die die freigegebenen Benutzerinformationen speichert. Erstellen Sie Synonymsoder Viewsin jeder anderen Datenbank, die auf die Benutzerdatenbank verweist.

Zuletzt würde ich eine Erweiterungstabelle (eine Tabelle mit einer Eins-zu-Eins-Beziehung mit der 'UserDB.Usertable') in jeder der 3 vorhandenen DBs erstellen, die die für diese App spezifischen Benutzerdaten enthält.

Bearbeiten: Basierend auf dem Kommentar unten

In diesem Fall muss die First db als Master-Benutzertabelle fungieren. Synonymsund eine Erweiterungstabelle in jedem der anderen DBS.

Wichtiger Hinweis : Bei diesem Ansatz werden die beiden anderen heruntergezogen, wenn Ihre erste App ausfällt. Stellen Sie sicher, dass jeder diesen Nachteil versteht.