これが私の問題です。私は Web アプリを構築し、そのアプリのドメインを説明するデータベースにデータを保持していました。その後、同じ組織用に別の Web アプリを作成し、別のデータベースを使用してそのアプリのドメインを記述し、データを保存しました...そして当然、さらにいくつかのプロジェクトが登場し、アプリごとにデータを単一のデータベースに分離しました. 開発に関しては、アプリのデータベースでデータ構造とデータへの変更を維持できるので、問題ないと思います。
これらのアプリが同じ組織に属していることを考えると、部門名、役職、ショップ名など、アプリ間で大量のデータが複製される傾向があります。これらのテーブルのほとんどは同じデータを保持していますが、各データベースで完全に同じというわけではありません。 、すべてのアプリで常に使用されるわけではありません。ただし、このデータへの変更は、すべてのアプリで (場合によっては異なる方法で) 変更する必要があり、管理の「面倒」が大きくなります。
そのため、データ間の同期を取得する方法を考えてきました。管理を簡単にしたい - 1 つのアプリ (または中央アプリ) で更新し、各アプリで必要に応じてすべてのデータベースを更新します。また、アプリ間でデータを共有するためのより良い方法 (新しいアプリで異なるアプリからのデータをマッシュアップするなど) も必要です特定の分析を可能にする）。私が参照しているデータのほとんどは、特定のドメインを説明するのではなく、組織を説明するコア ドメインの概念というよりも、制約として使用されます。
これを実現するためのいくつかの方法について意見を求めています。
私が最初に思いついたのは、前述の部門名のテーブルのような共通のデータ構造を取得し、それらをコア データベースに貼り付けることでした。データへの更新は、専用の Web アプリを介してこのデータベースで行われ、これらの変更にある種のオブザーバーまたはパブリッシャー / サブスクライバー パターンを適用します。変更が発生し、アプリが新しいデータを取得して必要に応じて使用できるようにします。GUID は、アプリ全体で同じデータを識別するための参照としてのユーザーである可能性があります。また、特定のアプリのデータベースに存在する必要はないが、役に立つ可能性のある読み取りおよび検索操作用の Web サービスを構築することもできます。
2 番目のアイデアは、各アプリが独自のデータを管理し、アプリが相互に観察できるようにすることです。1 つの変更は、変更が発生したことを同じデータ構造を共有する他のユーザーに通知できます。いくつかの GUID を引き続き使用し、任意のアプリでサービスを構築することさえできました。これもデータの重複という点では過度ではないと思いますが、各アプリが最終的に他のアプリに結合されるため、管理が難しくなる可能性があり、どのアプリがどの情報を制御するかについて責任を分散する必要があると思います.
このジャンルのデータ配布と同期が機能し、推奨されることさえあることに、私は本当に興味があります。意見やその他のアイデアは大歓迎です！