はじめに

SQLアンチパターンをRailsの文脈で読み解いていきます。
この記事では、Ⅱ部データベース物理設計のアンチパターン（9~12章）を取り上げます。

リンク

本文

9. ラウンディングエラー（丸め誤差）

特にお金とか無限の精度のがあるものは、Float型ではなく、Decimal型にしましょうという話。
私も一回踏みました。

class CreateProduct < ActiveRecord::Migration[5.1]
  def change
    create_table :products do |t|
      t.decimal :price, precision: 10, scale: 2
    end
  end
end

のように全体の桁数precisionと小数点以下の桁数scaleを指定するだけです。

10. サーティワンフレーバー（31のフレーバー）

enumをCHECK制約で管理するのはよくないという話。
とはいえ、Railsを使っている上で、そこまでないかと。私は、

class Bug
  enum status: %i[new in_progress fixed]
end

みたいなことをします。
Enumerize等のgemを使ったり、配列でなくHashだったり、configとか使って定数化したり、色々なバリエーションは考えられます。
私はまだこれで困ったことはありません。

勿論enumをテーブルで管理すれば、列挙子に廃止ステータスを持たせて、既存のレコードについては許容しつつ、新たに割り当てることはできないようにする等、色々と柔軟にできることは確かです。
それだって、Validationで何とかできるかもしれませんが。あまり綺麗にな設計にはならなそうです。

11. ファントムファイル（幻のファイル）

S3のようなクラウドストレージを使うこともあると思いますし、賛否あるでしょう。
ファイルを直接DBにいれるなら、

t.binary :file, limit: 15.megabytes

みたいにすればいいわけですね。

S3を使うのなら、fogとCarrierWaveを使えばいいのではないでしょうか。

12. インデックスショットガン（闇雲インデックス）

indexの張りすぎも張らなさすぎにも注意という話。
add_indexとindex: true等indexの貼り方さえ押させておけば、特にRailsに特化したことはなさそう。
あと、t.referencesすると勝手にindex張られるとか。