これは、複雑なシステムの非常に簡単な説明です。以下のストアとサービスには、さまざまなタイプの多数の関係と数百万のレコードがあります。さらに、いくつかのアプリケーションで使用されます。
多くのサービスを含む多数の店舗で構成されるプロジェクトがあります。これは単純な関係です。これらのサービスのほとんどはあまり変わりません。しかし、多くの場合、すべてのサービスをコピーする必要がある既存のストアをコピーすることによって、新しいストアが作成されます。
クライアントは、店舗が親会社をサポートすることを望んでいました。したがって、親会社は 1 つ以上の店舗を持つことができます。これは主に報告目的であり、店舗やサービスとの関係には影響しません。これは行われ、大したことではありません。
現在、クライアントから、親会社がサービスを作成して特定の店舗にプッシュできるようにしてほしいとの声が寄せられています。ただし、店舗は世界中にあるため、各サービスには独自の価格設定が必要です (在庫に関する考慮事項もあります)。表面的には、2 つの基本的なアプローチがあります。まず、店舗間で共有される 1 つの親会社のサービス レコードを作成し、各店舗の価格を保持するための異なる DB 構造を提供します。これに関する主な問題は、各アプリケーションがサービスの ID とストア ID を提供して、適切なサービス データを読み取っていることを確認する必要があることです。通常のロードと検索では、追加のテーブル結合が必要になり、データベースのオーバーヘッドが増加します。
2 番目のソリューションでは、親会社のサービス レコードのコピーを各店舗に作成できます。したがって、新しい DB エンティティを作成する必要はありません (親会社へのいくつかの参照を除く)。すべてのコードは、変更の知識がなくても通常どおり実行できます。これには、親会社レベルのサービスが変更されるたびにすべてのストアが更新されるようにするための同期サービスが必要になります。さらに、親会社に追加された新しいストアには、共有サービスを追加する必要があります。
正規化の観点からは、最初のソリューションが最適と思われます。ただし、メンテナンスから 2 番目の方法は実装が簡単で、サービスの処理方法の変更が少なくて済みます。ただし、同期プロセスは潜在的な障害点になる可能性がありますが、あまり頻繁に使用しないでください。
では、2 つのアプローチのコンセンサスは何でしょうか?