1

Eventsいくつかの共通のフィールド（、、）を持つdateモデルのグループ（それらを呼びましょう）があるRailsアプリがありますがtitle、user_idいくつかの「サブタイプ」が必要です。AにSalesEventはとがありarticle_idますamount。にはフィールドがあるInterviewEventかもしれません。comments等々。

満たす必要のある3つのビジネス要件を知っています。

  1. Events場合によっては、全体をフレームに収めたいと思うでしょう（つまり、「Eventsこのユーザーのすべてを取得し、月単位でグループ化して時系列に並べ替える」）
  2. それ以外の場合は、「サブタイプ」（「このユーザーが販売するすべての記事を取得する」）のみが必要になります。
  3. サブタイプの数は適度に多くなる可能性があります（まだ未定ですが、ユーザーのフィードバックに応じて約20と推定されます）

このモデルをサポートするためにテーブルを構造化する方法について考えています。これをモデル化するための5つの可能な方法を考え出しましたが、それぞれに独自の欠点があります。

  • オプションA：テーブルを分離する-sales_eventsとinterview_events。これにより、2）非常に単純になり、3）実行可能になりますが、1）実装が非常に面倒になります。
  • オプションB：単一テーブル継承。これは1）と2）を多かれ少なかれ簡単に解決しますが、より多くのnull許容フィールドを必要とするという問題があり、3）ではうまく機能しません。
  • オプションC：使用hstore-本番環境でPostgresを使用しているため、hstoreを使用できます-「タイプ」文字列フィールドによって管理される「データ」フィールドがあります。これは1）、2）、3）を解決しますが、postgresqlに結び付けられ、あまり馴染みのないテクノロジーに主要なビジネスオブジェクトを実装します。できればそれは避けたいです。
  • オプションD：への多態的なリンクを持つイベントテーブル***_event_data。基本的に、タイプとevent_data_idを持つイベントテーブルがあり、次にsale_event_data、interview_event_dataなどがあります。これは1）と3）を十分に満たしますが、2）結合が多いため、他のアプローチよりも少し弱いです。イベントとそのデータのリンクに関与します。
  • オプションE：販売has_one：イベント。これは、「他へのリンク」が「データ」部分にあることを除いて、オプションDと同じです。また、1）と3）を解決し、2）のいくつかの結合も含みますが、もう少し「クリーン」に見えます。ここにはポリモーフィックな関連付けはなく、「通常の」SQLの関連付けだけです。

今、私はオプションEを使用する傾向があります。しかし、誰かがそれについて明らかな不利な点、または他のオプションの1つでより大きな利益、または私が考えていなかったより良いオプションを見ているかどうか知りたいです。

4

2 に答える 2

1

私はあなたの提案したオプションのほとんどすべてを使用しました。hstore次の理由でオプションA、B、Dを削除しますが、 Postgresを知らず、使用しないため、Cについて話すことはできません。

  • オプションA：あなたが言ったように、別々のテーブルは維持するのが非常に難しいでしょう。イベントの構造を変更するたびに、すべてのsub_eventsテーブルで変更する必要があります。
  • オプションB：単一テーブル継承。私はそれを頻繁に使用して削除しました。データベースに表示されるものとモデルがどのように見えるかの間には、設計上の大きな欠点があるように感じました。nilフィールドもたくさん。
  • オプションD：*_event_dataへのポリモーフィックリンクを含むイベントテーブル。ポリモーフィックテーブルは、その目的を目的としたものではありません。これらはtype、モデルにさまざまなフィールドを設定する方法であるため、タイプを明示的に指定しなくても参照できます。

オプションEは問題ないようですが、外部キーはどこに保存する必要がありますか？わかりにくく、状況を維持するのが困難になる可能性があります。

個人的には、自分が書きたいコードを使用します。これを使用すると、後で読みやすくなります。より具体的なものが好きです。そして、モデルの名前の付け方を変更して、ニーズを満たすようにします。あなたは創造的でなければなりません！

私はむしろそのようなものを書きたいです：

conference.event_information.users OR
sales_event.settings.title OR
interview.shared_information.comments OR
event.interview_details.starting_at

そのすべての例で、私は古典has_manyとbelongs_to関係を使用します。

データ型と継承の概念全体が、問題を解決したり、物事を明確にしたりできない状況に陥る可能性があると思います。時々あなたは物事を少し異なって見る必要があるだけです。

お役に立てば幸いです。

于 2012-06-12T11:39:50.877 に答える
0

Railsはデフォルトで複数テーブル継承をサポートしていませんが、かなり厳密にモデル化することが可能であることがわかりました。

この記事を参照してください：

http://mediumexposure.com/multiple-table-inheritance-active-record/

基本的には、モジュールを使用してオプションDを「変更」します。WawaLooの答えについてはまだ考えていますが、これも検討する価値があります。

編集：複数テーブルの継承の詳細：「citier」と呼ばれる宝石http://peterhamilton.github.com/citier/index.html

EDIT2：私はmultiple_table_inheritanceを使用することになりました：

https://github.com/mhuggins/multiple_table_inheritance

しかし、私は結果にあまり満足していません。これはおそらく、ビジネスデータを永続性ポリシーと緊密に結合すること（ActiveRecordのように）があまり役に立たない場所の1つです。それは十分にうまく機能しますが、完全ではありません（特に、インスタンスメソッドは「継承」できますが、クラスメソッドはできません。スコープなどは、サブクラスごとに別々に繰り返す/混合する必要があります）。

于 2012-06-12T14:35:02.720 に答える