0

半分完成したプロジェクトをリファクタリングしようとしています。元の開発者は去りました。彼のモデル設計では、別の「期間」モデルが使用されています。したがって、割引オブジェクトには使用可能な期間があり、イベントには期間があります。

期間テーブル:

  create_table "periods", :force => true do |t|
    t.integer  "owner_id"
    t.string   "owner_type"
    t.datetime "begin"
    t.datetime "end"
    t.datetime "created_at",                               :null => false
    t.datetime "updated_at",                               :null => false
  end

日付に基づいてリスト クエリを作成するのが難しいと感じ始めています。期間テーブルを結合し、その終了日フィールドで並べ替える必要があります。

私が聞きたいのは、このアプローチの長所/短所は何ですか? それらを所属モデルに戻す方が理にかなっている気がします。

4

1 に答える 1

1

テーブルを作成することperiodは、必ずしも奇妙な慣行ではありません。そのような情報がプロジェクト開発者の相続人に届けられる限り。

また、たとえば 6 月など、特定の期間に発生したすべてのことを知りたい場合、テーブルを分割することは完全に理にかなっています。

つまり、私が言いたいのは、それはコミュニケーションとニーズに関するものだと思います. その機能がもう必要ない場合は、期間に関連するすべてのポリモーフィック テーブルに 2 つの新しい列を追加し、期間テーブルのすべてのデータをそれらの列に移行する移行をお勧めしbegins_atますends_at。

于 2012-04-05T07:06:45.703 に答える