最後は短くなった。なぜなら、より物理設計に近くなると異論がなくなるからである。言い換えると、論理設計は正解がない。設計者の裁量の部分が大きく、何が絶対的に正しいとは言い難い。 そもそも、アンチパターンとはなんだろうか？本書の著者によると 問…

想定不足により深刻な障害が起きるというアンチパターン。障害が起きるまで放置するのではなく、想定をし、予防をしようというもの。とくに運用後の体制について記述されている。 ベンチマークを取っておく、テスト環境を用意する。例外処理をきっちりやって…

MVCアーキテクチャにおいて、モデルを単なるCRUDの部品として扱ってしまうと、それ以外のコントローラなどがあらゆるモデルのオブジェクトを使って、肥大化してしまい、修正が大変になるという問題。「ドメインモデル貧血症」ともいう。 フレームワークによ…

アプリケーションの開発のルールをデータベース設計だけには適用しないということ。 データベースの設計者だけが特権的な位置にいるということがあるらしい。 よくわからないが、少なくともここで述べられている文書化やバージョン管理をしない（あるいは知…

SQLの実行結果のステータスを何も見ないなど、エラー処理を放置してしまうこと。 どのようなエラーがあるのかを知っていればほとんどこのような処置をすることはないと思うが。

擬似キーの欠番を埋めるとかいうことはやめましょう。ということ。擬似キーは内部的な値なので欠番が生じても何も問題ないはずである。 ただし、本当のコードつまり、人間が管理すべきコードとしてはあまり良くないかもしれない。このため採番用のテーブルを…

SQLを文字列から組み立て、かつユーザーが入力させる値を途中で組み込むときは、SQLインジェクション攻撃に気をつけましょうというもの。

パスワードを平文のままデータベースに保管してはいけませんよ、という内容。

ワイルドカードを使ったSQL文は避けろというもの。属性を加えるとエラーになったり、ワイルドカードですべての列を取得するのはパフォーマンスに影響するから、だめだよ。という。列名を明示的に指定しましょう。ということ。 確かに、使う必要のある列のみ…

スパゲッティな複雑なクエリを書くと、意図しない結果を出したり、デバッグも難しくなったりするというもの。 解決策としては分割統治を行うべきだということで以下の解決策を出している ワンステップずつ SQLを分割し、ワンステップずつ処理すべき UNIONを…

全文検索をSQLでやろうとして、LIKE演算子や正規表現で検索しようとすること。インデックスなどが使えないため遅い。全文検索エンジンを使いましょうというもの。 たしかにそのとおりですね。日本語の場合は単語境界をとるのが難しいのと、送り仮名など表現…

ランダムにデータを抽出する際にorder by rand()を使うと、件数が多くなると遅いよ、というアンチパターン。MySQLを使ったこともなければ、ランダムにデータを取り出すという要求もないので、知らなかったが、要は並び替えを常に行うので、遅いらしい。 で、…

最大値や最小値が得られた値について、その最大値をもつタプル（行）の別の属性（列）を取得したいとした時に、group by句に含まれない属性をselectの属性に含めてしまうというもの。 ほとんどのRDBMSではエラーになるが、MySQLとSQLiteはエラーにならないと…

NULLの振る舞いについて。本書ではNULLを使うことがアンチパターンでなく、一般の値としてNULLを使うことが良くないと述べている。 とくに、すべての項目にNOT NULLを使うように強制するのはよくないという。欠けている値を表現するには、何かの値を「欠けて…

インデックスの性質を理解して、闇雲にインデックスを作成したり、逆に全く設定しないということのないように、というもの。そりゃそうだ。 ただ、解決策に示されているのは、すでに運用中のデータベースに対するパフォーマンス改善としてのインデックスの作…

論理設計は議論すべき点が多いと思うが、物理設計以降になってくるとその通りとしか言えないものも増えてくる。