データベース（特にRDB）に長けてるセンパイに教えてもらった、
テーブル設計するときに心がけるべきことのメモです。
1. 全てのテーブルには目的がある
全てのテーブルには目的があります（当然ながら）。
例えばテーブルAはデータの実体を表すとか、テーブルBはXX画面の表示用とかとか。
自分で一から設計するときはあまり意識しなくても大丈夫ですが、
他人が作ったテーブルを変更するときは、
そのテーブルがどういった目的で作られたのかちゃんと理解するようにしましょう。
そのテーブルの目的に沿わない変更はしない方が、
結局見通しの良さやパフォーマンスの観点から良いことが多いです。
2. プログラムでマイグレーションする必要があるなら、まずテーブル設計を疑え
バージョンアップの際、テーブルレイアウトの変更やデータマイグレーションが必要な場合があります。
このときSQLを流すだけでマイグレーションが済めばよいですが、
SQLだと煩雑になりすぎるからプログラムを書いてマイグレーションしたいときがあります。
でもちょっと待ってください。
もしかするとそれは、テーブル設計がやたらと複雑過ぎるだけかもしれません。
一度立ち止まって、もう一度テーブル設計を考えてみましょう。
3. マイグレーションでは影響をゼロにするのではなく、ミニマムにすることを優先せよ
またまたバージョンアップのときの話です。
マイグレーションのときは既存のユーザへの影響をゼロにするのがベストですが、
まずは影響をゼロにするのではなく、ミニマムにする案を考えてみてください。
というのも、マイグレーションを行う時点で
バージョンアップ前後で何かしら矛盾を抱えていることが多く、
ゼロにしようと頑張っていると一向に解が見つからなかったりするからです。
まずはミニマムにする案を考え、
それからゼロにできないか考えてみましょう。
4. NULLは極力使うな（初心者の場合）
NULLは各種データベースで扱いが若干異なり、
安易に使うと意図しない検索結果が返ってきたりパフォーマンスの低下を引き起こしたりします。
適切に扱えればベストですが、
まだ経験の浅いエンジニアは安易にDEFAULT NULLにするのではなく、
他の値で代用できないか考えてみましょう。