私は明確な答えを持っていないことをすぐに言わなければなりません、そして実際にそれは原則的にはできません。 複雑な質問には単純な解決策はなく、複雑な質問には多くの正しい解決策があり、それぞれが独自の「座標系」（評価基準）で最適になる場合があります。 データ構造の分散設計の問題が関連する可能性のある「座標系」について説明しようとします。
適用の限界
Magento（WordPress、Drupal、Joomlaなど）などのWebアプリケーションの開発者のコミュニティを検討してください。 コミュニティには、アプリケーションの基本機能を開発する開発者のグループがあり、基本機能の独自の拡張機能を作成する開発者のグループが多数あります。エンドユーザーの希望に応じて、基本機能と必要な拡張機能をすべてまとめようとするインテグレーターがいます。
基本的な機能と拡張機能の開発者は、原則として、リレーショナルデータベースに保存されているデータを操作します。 リレーショナルデータベースでは、データ構造をより厳密に記述することができます-課された制限（外部キー、一意のインデックス）により、開発者は（特定の構造の作成者が描写したい）サブジェクト領域を理解しやすくなり、既存の構造を誤用しにくくなります。 キーと値のストレージと同じスケーラビリティと柔軟性はありませんが、それらの機能は、使用されるレベルのプロジェクト（数百と数百の同時作業ユーザー、データボリュームは物理サーバーのディスクサブシステムによって制限されます）、および柔軟性に十分です秩序を犠牲にして、開発の最終的な複雑さを高めることができます。
このようなアプリケーションのビジネスロジックは、ORMを介してデータベースと連携するプログラムコードのレベルで実装され、使用されるDBMSの特定の機能（SQLプロシージャと関数）は通常関与しません。
拡張機能は、基本モジュールの既存のデータ構造を使用し、基本構造に閉じた独自のデータ構造も作成します。 場合によっては、一部の拡張機能が他の拡張機能を参照する場合があります（ composerなどの依存関係マネージャーの存在は、互いに依存するモジュールの長いチェーンの出現にのみ寄与します）。
各モジュール（基本モジュールまたは拡張モジュール）は、独自の開発パスを通過します。開発パスでは、使用されるデータ構造に変更があります。 たとえば、MagentoモジュールMage_Coreのデータベース内のデータ構造を変更するファイルのリストからの抜粋です。
install-1.6.0.0.php ... upgrade-1.6.0.1-1.6.0.2.php upgrade-1.6.0.2-1.6.0.3.php upgrade-1.6.0.3-1.6.0.4.php
ここで、バージョン1.6.0.4の最終データ構造を取得するには、まずinstall-1.6.0.0.phpスクリプトを適用し、次にupgrade-1.6.0.1-1.6.0.2.phpからupgrade-1.6.0.3-1.6.0.4へのすべてのスクリプトを順番に適用する必要があります.php（なぜupgrade-1.6.0.0-1.6.0.1.phpではないのか-知りません）。 Magento ORMメカニズムを介したスクリプトは、新しい構造要素（テーブル、フィールド、インデックス）を追加し、既存の要素を変更し、廃止された要素を削除します。 同様のスクリプトは、Magentoの拡張機能で使用できます。基本的な機能は、必要なシーケンスでそれらを検出して適用します。 モジュール間の依存関係が与えられます。 一般に、非常に成功したアプローチであり、非常に複雑な（数百のテーブルの）データ構造を非常に独立して構築できます。 私の側では、改善したい点が2つあります。
名前空間
まず、モジュールレベル（Mage_Core、Mage_Catalog、...）だけでなく、データ構造のレベルでも名前空間を使用します。 拡張開発者の数が十分に多い場合、さまざまなモジュールでグループやメッセージなどの名前のテーブルが出現する確率は、非常にゼロではなくなります。 ほとんどの大規模またはスマートな開発者は、構造（aw_、amasty_、prxgt _、...）にプレフィックスを付けますが、一部のモジュールはccおよびcsvという名前のテーブルを作成することがわかりました。 名前空間の存在により、モジュール（投影されるサブジェクト領域のエンティティ）だけでなく、テーブルフィールド（エンティティの属性）の間でモジュールを「分離」できます。
宣言的な説明
次に、モジュールのデータ構造を作成するには、プログラムコード（命令型アプローチ）ではなく、 Hibernate Mapping Filesのようなxml記述（宣言型アプローチ）を使用します 。 この場合、基本機能には、データベースのデータ構造を変更せずにプロジェクトに関連するすべてのモジュールのxml記述を分析し、矛盾が検出された場合に診断メッセージを発行する機能があります（たとえば、モジュールBは定義されたエンティティ/テーブルに属性/フィールドを追加しますモジュールAではありますが、モジュールAの現在のバージョンでは、このエンティティは使用されなくなります）。
さらに、基本的な機能により、既存のデータ構造の宣言的な記述を復元できます（記述は、構造のメタデータに保存するか、テーブル/フィールド/インデックスの名前から復元できます）。 この場合、既存のデータ構造が新しいインストール可能な拡張機能（拡張グループ）の要件に準拠しているかどうかを自動的に診断することもできます。
まとめ
サードパーティの拡張機能を使用してWebアプリケーションに基づいてプロジェクトを展開した経験は、さまざまな疎結合チームが共同で一貫して最終的なデータベース構造を設計できるツールの必要性を示しています。 少なくとも、このようなツールは、名前空間を介してさまざまなモジュールの同じエンティティ/テーブルの分離を可能にする必要があります。 おそらく、このようなツールでは、ターゲットサブジェクトエリア（そのすべてまたは重要な部分のみ）の宣言的な記述が使用されます。 最大で、そのようなツールはアプリケーション自体が作成された言語に弱く依存します-さまざまなアプリケーション/ユーティリティ/コンソールから同じデータベースでデータを処理できます。むしろ、いくつかのプログラミング言語（php、python、java、c＃、 javascript、...）。
もしあれば、そのようなツールへのリンクをいただければ幸いです。