Edited at

SQLアンチパターンon Rails Ⅱ部(物理設計)

More than 1 year has passed since last update.


はじめに

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を使うのなら、fogCarrierWaveを使えばいいのではないでしょうか。


12. インデックスショットガン(闇雲インデックス)

indexの張りすぎも張らなさすぎにも注意という話。

add_indexindex: true等indexの貼り方さえ押させておけば、特にRailsに特化したことはなさそう。

あと、t.referencesすると勝手にindex張られるとか。