moqui - Moqui カスタム アプリケーションのデータ モデリングの問題

Question

私たちは、Moqui フレームワーク上で 1 つのカスタム プロジェクト管理アプリケーションに取り組んでいます。私たちの要件は、プロジェクトに関連する開発者に電子メールでチケットの変更を通知する必要があるということです。

現在、WorkEffortPartyエンティティを使用してプロジェクトに関連付けられたすべての関係者を保存し、次にPartyContactMechエンティティを使用して電子メール アドレスを保存しています。ここでは、WorkEffortParty と PartyContactMech を毎回反復処理して、チケットの変更に関する電子メールを毎回送信する必要があるすべての電子メール アドレスを取得する必要があります。

このような繰り返しを避けるために、プロジェクト レベルでコンマ区切りの電子メール アドレスを追加する機能を提供することを現在考えています。プロジェクト管理者は、チケット変更の電子メール通知を送信する必要がある関係者の電子メール アドレスまたはメーリング リストのアドレスを追加できます。

この要件のために、データ モデルについて調査しましたが、この情報を格納する適切な場所がありませんでした。このためにエンティティを拡張する必要がありますか、それともベスト プラクティスはありますか? この要件は、あらゆるプロジェクト管理アプリケーションで非常に役立ちます。このデータ モデリングの問題について、お役に立てれば幸いです。

Answer 1

ベスト プラクティスは、利用可能な既存のデータ モデル要素を使用することです。正規化されたデータ モデルを使用すると、データのクエリに多くの作業が必要になりますが、データ構造を変更することなく、さまざまな要件に柔軟に対応できます。

この場合、結合されたクエリを使用すると、プロジェクトの workEffortId に基づく単一のクエリで電子メール アドレスのリストを取得できます。大量のデータとメッセージ ボリュームを扱っている場合、ソース データを非正規化するよりも優れたソリューションがありますが、そうではないかと思います... 1 日に数千を超えるプロジェクトと数百万のメッセージを扱っている場合を除き、基本的なクエリと反復アプローチは問題なく機能します。

それを超える必要がある場合、Moqui での最も簡単なアプローチは、DataDocument と DataFeed を使用して更新をその場で ElasticSearch に送信し、それを大量のクエリとフィルタリング (任意に複雑なフィルタリングなどの要件を使用) に使用することです。

あなたの質問はオープンすぎて直接答えることができません。データ モデリングは複雑なトピックであり、コンテキストと使用目的を十分に理解していなければ、適切な答えはありません。一般に、何十年にもわたる経験に基づいており、多数の運用システムで使用されているデータ モデルから始めるのが最善です。Mantle UDM はそのようなモデルの 1 つです。