SQLアンチパターン@Rails②物理設計

パターン9:丸め誤差(ラウンディングエラー)

t.float value_wanted_precision

解決策

decimal型を使用する

t.decimal valuewanted_precision

ちなみにRailsのmigrationで指定できる型は、
http://stackoverflow.com/questions/17918117/rails-4-datatypes
とある(Rails4)。特にMySQLには厳しくて、unsignedとかもわざわざ有識者が作ったgemを入れないといけないので注意。

パターン10:31のフレーバー(サーティワンフレーバー)

t.string salutation
(上に入る値をMr,Mrs,Ms,Drなどに限定したい)

DBにはCHECK制約というものがあるが、Railsのmigrationには存在しない。そのため、アプリケーションフレームでバリデーションする必要がある。したがってこのアンチパターンはそのまま引っかかるわけではない。
ただ、その値をハードコーディングするべきか、という話はある。
たとえばenumっぽくこんなことはできる。

enum salutation: %i(Mr Mrs Dr)

しかし、これはアプリケーションコードなので拡張性がよくない。そこで、DB構造にそれを移す。

create_table :salutation do |t|
   t.string :salutation_name
end

create_table :people do |t|
   t.string  :name
   t.integer :salutation_id
end

とすれば、簡単に（データ挿入で）拡張できる。ただし廃止の際はデータを消去すると整合性がなくなるので、廃止であるという情報をデータ型に加える、というのが良い。

@ salutation table
t.boolean :is_deprecated

的な。

パターン11:幻のファイル(ファントムファイル)

外部のファイルなどをデータとして持つ際に、ファイルパスではなくファイルそのものをDBに格納すべきだという話。さすがに賛否両論あると思う。

ただ、パス方式をとった場合、そのパス先の画像に対しての参照整合性は自分が保障しなければならないので、DBの機能を利用したほうがいいという主張はある程度納得出来る。

パターン12:闇雲インデックス（インデックスショットガン）

「とにかくINDEXだ！！！」みたいな。インデックスによる理解の間違いが招く自体っぽい。ちょっと考えると、もしインデックスがとにかく貼ったほうがいいようなものなんだったら最初から機能に組み込まれているべきで、そうでないのなら何かしらの選択要素があるはずだ、くらいは考えても然るべきだと思う。

(ridgepoleの例より)
add_index "child", ["parent_id"], name: "par_ind", using: :btree

要するにindexは「貼るべき」カラムにのみ貼られるべきだ、というだけのお話。選択制が高くて、更新頻度の低いカラムにのみ貼られるべき。
インデックスの利用については各RDBSシステムに依存するのでここでは書かない。

②章終わり。