2021年のカスタムプラグインDBデータのベストコンベンションは?

都市固有のディスカッションを中心に据えた、賃貸不動産コミュニティのサイトを構築しています。ユーザーは、どの都市に詳しいか、またその都市との関係(現在居住中、過去に居住していたなど)を指定するデータを持ちます。また、投資を検討しているが専門知識がない都市にもユーザーは購読できます。すべての都市はカテゴリとして扱われ、カスタムフィールドにジオコードデータを格納することで、ユーザーが地図上で都市を閲覧できるようにします。

少し迷っているのは、データベース効率の観点からどのように構造を設計すべきかという点です。都市ページを表示する際、その都市の「メンバー専門家」を示すフィードを表示します。カテゴリページをレンダリングするたびに、すべてのユーザーをクエリし、彼らのカスタムフィールドや「専門家都市」のカスタムフィールドハッシュを走査する必要があれば、ユーザー数や都市数が増えるにつれて非常に遅くなるのではないかと懸念しています。

もしこれを独自の Rails アプリとして構築するなら、結合テーブルや has_many :through のようなモデル関係を使って簡単に解決できるはずです。ここで疑問に思うのは、結合テーブルを必要とするプラグインにおいて、推奨されるアプローチは何かということです。カスタムマイグレーションやカスタムテーブルは推奨されていないように見え、一般的にはカスタムフィールドか PluginStore を使う方が良いとされています。PluginStore に関する具体的なドキュメントは見つけられませんが、現在調査を進めています。

どの方向に進むにしても、Discourse 公式が推奨するアプローチについて確認しておくのが賢明だと考え、質問いたしました。

ありがとうございます :slight_smile:
Zach

「いいね!」 3

それは初期の頃はそうだったかもしれませんが、現在ではむしろ逆です。当社は、Poll プラグインや Voting プラグインのように、カスタムフィールドから独自のテーブルへ移行することが合理的だった場合、自社のプラグインも移行しました。

リッチなデータモデルを持つプラグインは、独自のモデル、テーブル、リレーションシップ、マイグレーションを作成すべきです。これは保守性が高く、優れたパフォーマンスを提供します。ただし、N+1 問題にはご注意ください :wink:

「いいね!」 5

ああ、なるほど、素晴らしいですね。そう聞いて安心しました。:wink: プラグイン内からコアモデルを変更する推奨方法はあるでしょうか?

カスタム定義やリレーションシップ(例えば、新しいテーブルとの hasmanythrough など)を追加したいと考えているのですが、カテゴリやユーザーなどの ID を新しいモデルの関数に渡す必要がある方法以外に、最適なやり方がよくわかりません。

この投稿を見つけましたが、回答が得られなかったようです。

「いいね!」 2

上記で触れた Poll プラグインにはいくつかの例があります:

「いいね!」 2

素晴らしいです。これが実現可能だなんて、とてもワクワクしています!ありがとうございます。

「いいね!」 3