書評も出揃ってる感がありますが、ようやく読み終わったので書こうと思います。設計でやってしまいがちな、ダメダメなパターンを体系化して、名前をつけたものです。なってしまうのか、どうやって回避するのか、使っても良い場合があるとしたらどういう場合か、も書いてあります。年齢とかならそれに越したことはないと思います。自信ない人は是非読むべきです。設計とか長くやってる人も、読んだほうがいいでしょうね。デザパタなんかと同様に、今後はパターン名知らないと、話が通じなくなっちゃう可能性がありますから。F○CK!」とかそんな感じでお話ができるようになると、世の中少し幸せになるんじゃないかなー、と思うわけです。IDリクワイアド(とりあえずID)さてさて、中身ですが、書いてあることには概ね同意だし、上手くまとまってるなー、とは思うんですが、やっぱみんな色々言ってる「IDリクワイアド」ですかね。自然キーですが、僕は基本的にサロゲートキーでやるべきだと思っています。自然キーには必要に応じて一意制約をはるのがいいかな。経験上、自然キーが本当にキーだったことは一度もありませんでした。何か追加の情報(リビジョンとか日付とか)入れれば主キーに大抵なるんですが、そんなんやるくらいなら、サロゲートキー入れたほうがよっぽど楽だと思います。テーブル名とキー名ですが、これは規模によるんじゃないかな、と思います。そんな感じにしといた方がいいかもいれませんね。みたいな規則でキー名付けると、キー名がすごく長くなってしまいます。いいんじゃね?と思います。ミスるのは、テーブル別名に「a」とか「b」とかイミフなのをつけるのが良くないのであって、ちゃんとテーブル別名「bugs」ってつければそういうミスは防げると思います。「IDリクワイアド」はこの辺にしといて。キーレスエントリ(外部キー嫌い)あとは、「キーレスエントリ」かな。これは言ってることは分かってて、DB設計者の立場としてはその通りだな、と思うんですが、(一方で僕は開発者でもあるので)、開発者としては「外部キー邪魔だな」と思うことがしばしばあります。テストデータ入れるのがすげー面倒くさくなるんですよね、外部キーあると。DB管理者としては、外部キーあると、テーブルの変更が辛くなる場合がありますね。新しいテーブルを用意して、そっちと入れ替えるような変更ができなくなるんですよね。持っている制約ってのはちょっとプア過ぎるよなー、と思います。チェック制約みたいなのも、テーブルまたぐようなチェックとかできないから、結局アプリでやるしかないし。そんな感じなので、バリデーションはアプリでやった方がいいんじゃないかなー、と思います。外部キーは、「テストデータ出し入れするときだけ、一時的にオフるモード」とかあれば、もうちょい積極的に使いたいなー、とは思うんですが。ファントムファイル(幻のファイル)「ファントムファイル」も微妙じゃね?って意見をどっかで見たのですが、僕はこれアリだと思いました。「ファイルは常にディスクに置くべき、と考えるな。使えるよ」っていう書き方だったので、それはまあその通りだよな、と思います。サーバから見える所に置きたいか、によって使い分けるのがいいんじゃないかな、と思いました。ドライバの設定とかを見直さないと、多分デフォルト設定だとデカいデータを置けないんじゃないかな、と思うんですが、その辺あんまちゃんと書いてないのが微妙というか、ちょっとアンフェアだな、と思いました。まとめまあ最初に書いたとおりですけど、経験の少ない人にも熟練者にもおすすめできる本だと思います。中に読んでみるべし!だと思います。追記コメントいただきました。ありがとうございます。MySQLならFOREIGN_KEY_CHECKSとかあるんですがそういうのではなくて?ごめんなさいごめんなさい。カジュアルかつ、いい加減に書きすぎました。データロードの問題は、問題の半分の半分くらいなんです。いうのを、いい感じに空気読んで設定してくれるツールが現状ありせん。うざくて仕方ありません。うまくゴミデータを削除する必要が生じたりして、そんなことしてると一体僕は何をテストしてるんだろ?っていう気分になったりします。2倍悲しかったりします。(うーん、このへんは伝わるか良く分かんないけど、僕はこの辺かなり悩みました。みたいなやつをテストするときに、うっかり依存関係忘れちゃうし、こういうのムズいなー、と思います。書いてないから動向良く分かんなくて、結局この辺の必勝法良く分かんないなー、と思います。オフらずかつ、テストコードでテストデータロードしてたり本番環境からマスタデータの引き上げとかやってる人いたら、どんな感じでやっているのか、是非是非教えてほしいなぁ、と思います。