シノニムを使用して、重複したテーブルを作成しないようにすることをお勧めしますか？

まったく同じデータベースのコピーが3つあります。3つのデータベースにはすべてUsersテーブルがあり、ユーザーは常に3つのデータベースすべてにまったく同じ設定で存在します。ユーザーを追加または編集する場合は、3つのデータベースを更新する必要があります。

Usersデータベース2と3からテーブルを削除し、Synonymデータベース1を指すものに置き換える方が良いでしょうか？

ここに私が考えることができる長所/短所があります：

長所

• 簡単なメンテナンス。3つではなく1つの場所でユーザーを更新できます
• ユーザーIDはデータベース間で一致します（多くのアドオンアプリはUserIdに基づいているため重要です）

短所

• これは標準的な手順だとは思わないでください。
• ユーザーはデータベース間で同一の設定をする必要があります
• （下記のgbnの回答から）データベース1がダウンした場合、データベース2と3も利用できなくなります。また、復元のイベントでデータが一貫していないという潜在的な問題があります

これは、テーブルだけでなく、データベース間で同一の設定を含むいくつかの異なるテーブルに対して検討しているオプションですUsers。わかりやすいので、この例ではユーザーを使用しています。

同じユーザーのデータベースが3つあるのはなぜですか？

1つのデータベースが現在ダウンするとどうなりますか？

これらの質問をしているのは、他の2つのデータベースの使用を妨げるユーザーソースデータベースのConが、思ったほど大きな問題ではないかもしれないからです。

さらに、データベースがダウンした場合、その期間中に他の2つのDBでユーザーが変更されると、すでに一貫性の問題が発生します。文脈がなければ最高のアドバイスができるとは思いません。

今は、ユーザー用に4番目のデータベースを作成し、そこでのみ変更を加え、他のデータベース間で同期します。本質的に同じデータを3つの場所で変更することにより、すでに分散非正規化されており、おそらく既に一貫性の問題があります。フォールトトレランスが重要な場合、このスキームは複数エントリの問題を解決する際にそれを提供します。

既存のデータベースを使用するのではなく、この4番目のユーザー/設定のみのデータベースを使用することは、他のリソースに縛られたり、頻繁に使用されたりしないため、ダウンする可能性が低くなるため、良い戦略だと思います。あなたはこれを行うことができないと言ったことがわかりましたが、その理由はわかりません。メインデータベース上のアプリケーションは、ユーザー編集を直接サポートしていますか、それともユーザーが他の場所に向けることができる完全に独立した機能を編集していますか？

確かに、この「正規のユーザーテーブル」のアイデアでは、同義語を使用するかデータを同期するかに関係なく、ユーザーDBのダウン中にユーザーを変更することはできませんが、それは問題ないようです。問題を修正して、それを持ち出してください！ソースが1つ、編集する場所が1つ、破損した場合は修正するものが1つあります。同期により、他のすべてのデータベースには作業可能な一時コピーがありますが、編集はできません。システム間でのデータの重複を最小限に抑えることは、大きな有用な目標です。同じデータを3か所に入力することは深刻な問題です。

ユーザーIDがすべてのアプリケーションで異なる場合、より多くのコメントに対処するには、2つの新しいデータベースの計画的なダウンタイムを真剣に検討して、メインデータベースと同期させる必要があります（アイデアが必要な場合は別の質問をしてください）これを達成する方法については、トリッキーですが、それほど難しいことではありません）。

ビジネスニーズを分析し、メインデータベースに問題のないユーザーデータが必要であることがわかった場合でも、それを正規として使用し、類義語または同期から選択して、計画外のダウンタイムがすべてのデータベースに与える影響に対処します。

シノニムを使用することのもう1つの欠点は、各データベースのユーザーに対して適切なFKを使用できなくなることです。

欠落している「Con」があります

復元時に、ユーザーが（同義語の）ターゲットデータベースに存在しない可能性があります。破損しているとし、バックアップから復元する必要があるとします。

つまり、シノニムを使用すると、実際には発生しないデータベース間の参照整合性が想定されます。

これの別の結果は、これから回復しようとすると、ユーザーIDが一致しないことです。（復元後にユーザーを追加することにより）。ただし、先ほど述べたデータベース間の参照整合性のため、とにかくこれを想定しないでください。

だから、それをしないでください...

dba.seの関連する回答：復元後の「クロスデータベース参照整合性」について、非dboスキーマと新しいデータベースをいつ使用するかの決定基準

データベースプラットフォームに応じて、データベース2および3のテーブルを削除し、それらをデータベース1のテーブルのマテリアライズドビューに置き換えるという別のオプションがあります。

長所

• 簡単なメンテナンス（データの）
• 一致するID
• 停止は他のデータベースには影響しません（少なくとも変更が必要になるまで）
• 任意のデータベースを使用して、テーブルを回復できます。

短所

• データは、更新スケジュールと同じだけ最新です。
• テーブル定義が変更された場合、マテリアライズドビューも変更する必要があります。

また、ルックアップの頻度、更新の頻度、およびデータ変更の頻度に応じて、これは同義語ソリューションよりも多くの負荷をもたらす場合もあれば、そうでない場合もあることに注意してください。

更新： FrustratedWithFormsDesignerのコメントは、本質的に、マテリアライズドビューを実行できないプラットフォーム向けのマテリアライズドビューです。スクリプトを使用して、テーブルを定期的に同期できます。1つのデータベースがマスターとして指定されている場合、すべてのスクリプトはそれに基づいて変更を加えることができます。これには、具体化されたビューのすべての長所と短所があります。組み込みの機能を利用できなかっただけです。

共有ユーザー情報を保存する4番目のDBを作成します。作成するSynonymsかViews、Users DBを指すその他の各Dbsで。

最後に、そのアプリに固有のユーザーデータを保持する3つの既存の各データベースに拡張テーブル（「UserDB.Usertable」と1対1の関係を持つテーブル）を作成します。

編集：以下のコメントに基づいて

その場合、最初のデータベースをマスターユーザーテーブルとして機能させます。Synonymsその他の各データベースの拡張テーブル。

重要な注意：このアプローチでは、最初のアプリがダウンすると、他の2つのアプリも一緒にプルダウンされます！誰もがこの欠点を理解していることを確認してください。