データベースの正規化と依存関係

3〜4つの相互依存プログラムを開発しています。それらをfoo bar bazとauthと呼びます。お互いに独立してほしいです。各プログラムを他社にライセンス供与する場合を想像してみてください。fooとbarが必要な企業もあれば、bazだけが必要な企業もあります。authを独立しておくことも良い方法のようです。

コンテキスト：authはすべてのシステムの認証を処理します。authのメインのusersテーブルには、user_id、email、password、first、lastがあります

fooには、アプリケーションの特定のフィールド（user_id、role_idなど）を持つusersテーブルもあります。

各システムには独自のデータベースがあります。過去に、各アプリケーションから認証データベースへの外部キーを作成しました。他のデータベースから更新権限を削除しましたが、特定の関連フィールドへの選択アクセスを許可しました。これは緊密な依存関係を作成するため、悪い解決策のように見えますが、ユーザー名と電子メールをfoo、bar、またはbazデータベースに格納する必要がないように、dbを正規化することができました。

すべてのデータベースに情報を保存する方が良いでしょうか？または、認証IDをfoo barとbazに保存し、apiを使用してauthIdを使用してユーザー情報を取得する方が良いでしょうか？

同様に、3つのシステムすべてに顧客がいる可能性があります。確かに、auth dbに依存関係を作成するのは悪いようですが、3つすべての顧客のdbについてはどうですか？

または、1つの中央データベースを作成するのに最適なソリューションです。1つのユーザーテーブル。

他の提案？

4つの独立したサービスがある場合、それらは独立する必要があります。一般的なDBまたは類似のデータベースでデータを共有する必要はありません。単純に依存させるだけです。

本番環境で単一のDBを共有しても問題ありませんが、サービスは独自のスキーマを使用する必要があります。DBが共通のコンテナーとして存在するのは、単一のLinuxサーバーが4つのサービスすべてを実行できるのと同様です。

各サービスには独自のAPIが必要であり、これがそれぞれのAPIにデータを出し入れする唯一の方法です。したがって、認証サービスはユーザーを格納して認証を実行しますが、ユーザーを識別するためのトークンを返します。このトークンは、他のサービスがどのユーザーがどのユーザーであるかを記憶するために使用するものですが、それ以外の場合、ユーザー認証に関する知識はまったくありません。

これらの実装を考える最も簡単な方法は、自分が書いているサービスではなくサードパーティのサービスを使用することに決めた場合、自分の代わりにStackExchangeのOpenIDサービスを使用した場合はどうするかを考えることです。それをアーキテクチャに置き換えることができれば、優れた独立した設計になります。

あなたの例は少し抽象的ですが、私の考えをざっと見てみましょう。

オプションA：私の経験では、これはあなたの理由に関係なく常に悪いです。MSSQLのようなDB はフレンドデータベースなどを持つことができますが、データがリンクされている場合、同じDBにある必要があります。

オプションB：ここで何が起こっているのかわからない、すべてのDBにクエリを実行して結果をまとめるAPIを追加していますか？これはより良い方法ですが、そのAPIの上にAppsがあり、それらのデータレイヤーの一部であり、実際にDBの1つだけを使用している場合、なぜ他のユーザーがデータレイヤーにあるのでしょうか。

オプションC：これはうまくいきますが、無関係なデータを含む大きなデータベースを1つ持つのは良くありません。プログラムを互いに独立させたいですか？これはそれを助けません。

オプションD

私の提案は、userIdの概念から認証を抽象化することです。あなたの認証アプリはユーザーとロール（またはあなたがすべて現代に行くなら約束など）に関係するべきですこのデータは認証DBに存在するべきです

各アプリには、ユーザーごとにデータをグループ化するためのuserIdが必要です。また、auth呼び出しを行い、ユーザーをユーザーに識別するための関連データも必要です。これは、userId（アプリに対して一意）、実名、authusername、使用する認証サービスになります。このデータはアプリDBに存在する必要があります

データベースはそれらの間に接続があってはなりません。概念的には、認証アプリとしてではなく、認証サービスとしてFacebookを使用できるはずです。

fooユーザーをbarユーザーに関連付けたい場合は、さらなるユーザーリンク情報が必要になることがあります。

LDAPなどでシングルサインオン（SSO）を実装することをお勧めします。組み込みの認証アプリを独自の既存のユーザーデータベースに置き換えることができるため、大規模な顧客もおそらく恩恵を受けるでしょう。SSOをサポートしていない小規模のお客様の場合、アプリをデフォルトの認証アプリとともに出荷することで、導入を簡素化できます。