ポケモンを題材に「SQLアンチパターン」を実践してみる

以下のアンチパターンが紹介されている

『SQLアンチパターン』を読み始めるきっかけによさそう

複数の値を持つ属性をカンマ区切りなどで無理やり文字列として格納するのは、「信号無視（SQLアンチパターンの第1章）」と呼ばれるアンチパターンです。

全てのtableに無闇にid列を設けてしまうのは「とりあえずID（SQLアンチパターン第3章）」というアンチパターンです。

スキーマ定義に今後更新されうる制約を直書きし、ALTER TABLEで変更を加えるのは「サーティーワンフレーバー（SQLアンチパターン第10章）」と呼ばれるアンチパターンです。

新たにタイプを追加する際は（略）スキーマ変更ではなくデータの追加という形で実現できます。

「恐怖のunknown（SQLアンチパターン第13章）」と呼ばれるアンチパターン

不明な値を-1で表現 → 平均の計算などに使えてしまう

回避方法：NULLを使う

「外部キー嫌い（SQLアンチパターン第4章）」というアンチパターン

外部キーが宣言されていれば、「レコード削除の時点でエラーになる」 or 「自動でCapturesテーブルの該当行も削除される」という挙動になったはず

削除後に欠番になった trainer_idを無理やり埋めようとするのは、「擬似キー潔癖症（SQLアンチパターン第21章）」というアンチパターンです。欠番はそのままにしておきましょう。