Postモデルのカラムを最小限にして、演算できる値はpost.rbで関数定義する

[Fumiya-Matsumoto]

概要

Postモデルについて、演算処理できる値のカラムが存在するため、DBから消し、post.rbに演算関数を定義する。

目的

演算的に求まる値は整合性観点から持たせない方が望ましいため。

タスク

• [x] Postモデルから演算処理できる値のカラムを削除する
• [x] Model側に関数を記述（例：distanceとtimeからpaceを算出）

  将来的な検討事項

• アダプター層、サービス層の導入
  • Model側に処理が増えると、責務が集中し本質的でないコードが増える（Modelがファットになる）
  • 変換処理を担当するアダプター層、サービス層などを導入し、レイヤーの責務を明確にする
  • Rails：サービス層の導入
• RDBMSのViewを導入
  • ビューとはテーブルから取得したいデータの条件を定義してあたかも独立したテーブルのように扱えるようにしたもの。
  • ビューそのものはデータを持たず、元となったテーブルからデータを参照する。
  • 例えばテーブルの一部のカラムだけを取り出したビューを作成し、他のユーザーにはビューだけを閲覧できるように権限を設定するといった利用ができる
  • DBのビューを使ってみたらRailsのコード修正が(ほぼ)要らなくなった話
  • ビューの作成
• OLTP、OLAPを理解する
  • ユーザーリクエストを受け付けるアプリケーションとは別に、ジョブを実行し正しい値に戻すことを行います

[Fumiya-Matsumoto]

現状

改善案

演算や抽出で作れる値のカラムは全て除去

[Fumiya-Matsumoto]

PostRecordから「pace」も除去する

[Fumiya-Matsumoto]

paramsの処理について

1. paceなど既存のカラムの値を使って演算できるものは、modelにインスタンスメソッドで記述
   • データベースへの保存前に処理が必要なものはcontrollerに記述
   • 例）params[:record][:distance]で受け取った値をparams[:record][:kind]の値によって変えたい場合
   • 前提：distanceの単位はmであってほしい
   • kindの値が1, 2, 3のどれかの場合は何もしない（この場合、単位がmの想定）
   • kindの値が4, 5, 6のどれかの場合は1000倍する（この場合、単位がkmの想定）
   • 上記のように、保存前に必要な処理はmodelにクラスメソッドとして定義するよりもcontroller内に書く方がわかりやすいと判断。