実施して弊社では有志でSQLアンチパターンの読書会を実施しています。週一回、1章ずつ、1ヶ月で4章分を実施してきました。今でこそこんなことはやらないだろうという話でも、実は昔自分でやってしまったことがあるとか、誰かが経験したことがあるといったパターンもあり、心にぐさっと刺さる話もありました。今回は既に実施した第1章〜第4章について、まとめと感想を書いていきたいと思います。ジェイウォークカンマ区切りとかで複数の項目を1カラムに入れ込んでしまうジェイウォーク。これは検索がツラい、インデックス使えない、JOINがツラいなど、ツラいことばかりなので横着するのはやめようねという話です。今後ともやることはおそらくないでしょう。基本的には、ジェイウォークが必要になる状況はかなり限られるのではないかと思います。ナイーブツリーそもそもRDBに階層構造を格納するのは難しいのですが、本ではナイーブツリーとして紹介されている隣接リストの他に以下の手法が紹介されていました。閉包テーブルこれらの手法はそこまで単純でもなく、ナイーブとして紹介されている隣接リストについては、再帰クエリを利用すればツリーへのクエリ実行もそこまで複雑になりません。MySQLなどでは利用できませんが。決めるのがいいと思います。Modelというものがあることも知りました。詳細はhttp://qiita.com/StewEucen/items/e0487c39285a9d6b7863などをご参照ください。実際に将来的に利用することがあるかどうかは不明ですが。IDリクワイアド結論としては、id列はあってもなくてもどちらでもいいのではないか、フレームワーク側に合わせてid列を付けることにそこまで害はないのではないかという話になりました。Recordを使っているような場合、idカラムがあったほうがかなりプログラムは書きやすいです。キーレスエントリ外部キーは面倒がらずにきちんとつけておこうという話でした。これについても特に異論はありません。確かにテストのときなどで複雑なデータ構造を作る時に外部キーがあると面倒だったりしないでもないです。そこはきちんと自動化するなりして対応しようという話になりました。以前、ゆるゆるのデータベースのシステムリプレースを行ったことがあり、その際に整合性が取れていないデータが多数あって非常に困ったことを思い出しました。それを踏まえても、外部キー制約はきちんと付けていこうと改めて思った次第です。今後、引き続き5章からを実施していきますが、いい復習になりますし、楽しい議論もできるので、今後も楽しみながら参加していきたいと思います。採用メンバー紹介リモートワーク健康管理ソリューション・サービスお問い合わせ見積もり依頼や詳しいご相談など、クラウド・AWSに関する困りごとをお気軽にご相談ください。以下のお問い合わせ先から受け付けています。お問合わせはこちら※通常1営業日内にご回答いたします。