2013-05-01から1ヶ月間の記事一覧
最後は短くなった。なぜなら、より物理設計に近くなると異論がなくなるからである。言い換えると、論理設計は正解がない。設計者の裁量の部分が大きく、何が絶対的に正しいとは言い難い。 そもそも、アンチパターンとはなんだろうか?本書の著者によると 問…
想定不足により深刻な障害が起きるというアンチパターン。障害が起きるまで放置するのではなく、想定をし、予防をしようというもの。とくに運用後の体制について記述されている。 ベンチマークを取っておく、テスト環境を用意する。例外処理をきっちりやって…
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を使うように強制するのはよくないという。欠けている値を表現するには、何かの値を「欠けて…
インデックスの性質を理解して、闇雲にインデックスを作成したり、逆に全く設定しないということのないように、というもの。そりゃそうだ。 ただ、解決策に示されているのは、すでに運用中のデータベースに対するパフォーマンス改善としてのインデックスの作…
論理設計は議論すべき点が多いと思うが、物理設計以降になってくるとその通りとしか言えないものも増えてくる。
画像データなどをデータベースに格納せず、格納先のみを保存して、画像データなどを外部に保存するのは以下の様な問題がある、という指摘。 データベース上のファイルを削除しても外部ファイルは自動的に消えないという問題。 トランザクション分離がサポー…
IN句をつかったCHECK制約だけで列の値を制限するやり方には問題がありますよ。という指摘。プログラムで言うところの列挙型(ENUM)のようなもの。MySQLでも同様の機能があるようだ。 問題点は以下のとおり。 許可されている値の一覧がわからない。CHECK制約…
小数を格納するのにFLOATやDOUBLE, REALなどを使ってしまい、誤差がでてしまうというもの。金額の計算などにはNUMERICやDECIMALを使いましょう。はい。そのとおりですね。
顧客テーブルの属性に毎年、集計データの列を追加するという、ちょっと悪夢のような設計が紹介されていた。テーブルのタブル(行)の長さが変わるというのは運用上、物理的な格納効率を悪化させることがある。また、列が追加されるということは、SQLを実行す…
ジェイウォークのように繰返し項目をテーブルを分割せずに対応する方法の一つ。ジェイウォークは区切り文字を使って一つの属性に押し込めていたが、このパターンでは繰返し項目を単に番号をつけて列を分割する。 例えば、住所録に電話番号を複数格納する必要…
ある参照整合性制約を設定しているテーブルがあったときに、そのテーブルに対し別のテーブルの主キーに依存する参照整合性制約を設定したいときにはどうすればよいか?というもの。 このときに、別の項目にどのテーブルとの制約かという属性と、外部キーを一…