最後は短くなった。なぜなら、より物理設計に近くなると異論がなくなるからである。言い換えると、論理設計は正解がない。設計者の裁量の部分が大きく、何が絶対的に正しいとは言い難い。
そもそも、アンチパターンとはなんだろうか？本書の著者によると
問題の解決を意図しながらも、しばしば他の問題を生じさせるような技法
とある。しかし、論理設計においてはたいてい他の問題を生じさせ、絶対の正解がない。また、絶対の誤りもない。よって、この定義に従うと、ほとんどの論理設計の技法はアンチパターンである。本書で紹介されているアンチパターンの解決法もアンチパターンである。
一方で、このようなことも記述している。
とあるが、本当にこれらはミスなのだろうか？そうではなくて、単にメリットとデメリットが十分に把握できずに選んでしまった技法（解決法）の一覧である、という言い方をすべきではないだろうか？途中で記述したが、この本を読んだ人で最もまずい使い方は、このアンチパターンの内容は絶対にやってはいけないとする規約を作ってしまうことである。ただし、物理設計以降はそうとも言えないものも含まれている。SQLインジェクションなどをそのままにしていい理由などないため、そのとおりだろう。
途中でも記述したが、この本の著者はおそらく「リレーショナルモデルとして自然な設計をしましょう」ということが言いたかったのではないかと思う。それをアプリ側の都合による（実装上の都合による）、凝った設計をアンチパターンとよびたかったのではないだろうか？
デザインパターンの目的は再利用を目的とした設計というものに語彙を与えた、ということであった。これに対し、その反対を意味するアンチパターンとは一体どういう意味があるのだろうか？語彙を与えたという意味ではいいのかもしれないが、常に誤った設計でもないものにたいし、アンチパターンとしての語彙を与えるというのは、多くの人にミスリードを与えかねないと思う。
