はじめに
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張られるとか。