Moqui には、OFBiz に対してマルチテナント機能でさまざまな追加機能がありますが、はい、1 つのアプリ サーバー (またはアプリ サーバーのクラスター) とテナントごとに 1 つのデータベース (またはデータベースが分割されている場合はテナントごとに複数のデータベース) という同じアプローチを使用します。 .
単一のデータベースで多数のテナントを実際にサポートするには、多くのツールが必要です。基本的に、マルチテナント レイヤーに機能を組み込んで、アプリケーションのニーズを処理するだけでなく、通常はデータベースで直接実行されるその他すべて (他のアプリケーション、レポート、エクスポート/移行、必要に応じて分離されたバックアップなど) を処理する必要があります。非常に大規模にスケーリングする場合は、複数のデータベース サーバー間でテナントをシャーディングするためのサポートも構築する必要があります。つまり、適切かつ完全に行うことは簡単なことではありません。
100 テナントはそれほど悪くありません。テナントごとに 1 つのデータベースでそれを行うことができます。テナントをプロビジョニングするための自動化を構築するのが最善であり、Moqui に既にあるテナント プロビジョニング サービスに基づいてそれを行うことができます。たとえば、各データベース サーバーを 50 または 100 などのテナントに制限したい場合は、ロジックを追加して、複数のデータベース サーバーにまたがるテナントを "分割" することもできます。この方法で数千のテナントにスケーリングできますが、もちろん、他のスケーリングの詳細を処理する必要があります。
各エンティティに tenantId を追加する方法を使用することも、エンティティ ファサードにこれを自動的に実行させることもできます (おそらく、テナント共通グループ内のエンティティを除くすべてのエンティティに対して)。テナント全体でレポートする必要があり、テナントあたりのデータ量がそれほど多くない場合は、これが最適な方法かもしれません。
カスタム エンティティに対してのみこれを行うこともできますが、必要な機能によっては、これを Moqui エンティティにも追加する必要がある場合があります。たとえば、ユーザーを異なるテナント間で分離する場合は、tenantId を UserAccount と他のほとんどのセキュリティ エンティティ (承認、ユーザー グループ、アクセス許可など) に追加する必要があります。また、tenantId を非 PK フィールドとして UserAccount に追加し (extend-entity を使用して元のエンティティ定義を変更しないようにする)、認証されたユーザーに基づいて (またはユーザーの場合は別の結合テーブルで) テナントを検索することもできます。複数のテナントにアクセスできる場合があります)。
複雑さと可能なバリエーションは無限大です...すべてはあなたが何をしたいかによって異なります!
これに最も近い概念は、Mantle データ モデルの Organization Party です。同じシステム内の複数の組織をサポートするようにさまざまなものが設計されていますが、それらの間に厳密な分離はありません。これは、傘下の組織内の複数の部門やその他の小規模な組織向けです。