SQLアンチパターンを読んだ人がまとめた記事を読んだ1

失敗から学ぶRDBの正しい歩き方を買おうとしたんだけど、3000円くらいするので、先にSQLアンチパターンをちょっと勉強してから買うことにした。本当はオライリーSQLアンチパターンも読んだ方がいいんだけどこれも3000円くらいするので、先にネットで齧ろうと思う。読んだのはこの記事です。

ざっくり見た所感

アンチパターンに名前がついている

デザインパターンでいうシングルトンパターンとか、リポジトリパターンとか、名前を聞いて他の人と考えを共有しやすいのでいいですね。

結構有名な本なので別の職場の人との話題にしやすそう

今の自分の会社みたいに、同じ会社の人がいろんな現場に行ってていろんな言語やってると、共通の話題ってAWSとか、JSとかの話になりがちなんですが(みんなだいたい使ってるから)、DBもそのうちの一つなので、アンチパターンの話はしやすそうですね。

ふわっと、「これはやらないだろ」と思ってることも、じゃあなんで?って聞かれた時に答えられる内容が書いてある気がする

内容を読んだ所感とかメモ

1部 データベース論理設計のアンチパターン

1章 Jaywalking(信号無視)

「列にカンマ区切りでユーザを格納」!!!!? 絶対やらないですけど都市伝説では聞いたことがあります。分けられるデータを無理やり一つのレコードに詰めるのはやめた方がいいと思います。多分こういうのやる人は「一レコードで全部取れた方がいいでしょ」とか思うんでしょうけど、アプリケーションから一つ一つのユーザをカンマ区切りで取得するのも面倒です。

2章 Naive Trees(素朴な木)

「ブログのコメント欄をスレッド形式で見れるようにしたいよね・・・」の時にどんなテーブル設計をするかって話らしい。 「孤児になったの行を綺麗にするために定期的にスクリプトを実行しなければ」→個人的には、すでにコメントがついているメッセージが削除される場合、それを物理削除せずに、削除フラグ立てればいいのではと思った。で、表示は「すでに削除済みです」みたいな。 階層を同じカラム内でスラッシュ区切りで書くのは微妙かなと思う。でも、この本、「こういう検索はRDBでは問題なくできるからこのやり方は問題ない」みたいな書かれ方してて良いな。スラッシュ区切りは無しだと思うけど。

3章 ID Required(とりあえずID)

主キーはレコードが一意であることを示すキーだから大事だよって話。「疑似キー(idなど) : 対象領域をモデル化したテーブルに意味を持たない人工的な値を格のして主キーとする」。だからって行って全部のテーブルでIDを持たなきゃいけないわけじゃない。

4章 Keyless Entry(外部キー嫌い)

とりあえず外部キー使おうねって話。

5章 EAV (エンティティ・アトリビュート・バリュー)

同じテーブルの同じカラムには同じ属性のデータを入れようっていう話。

6章 ポリモーフィック関連

ヨクワカラナカッタ・・・。正規化しすぎてよくわからなくなっちゃう感じか?

7章 マルチカラムアトリビュート(複数列属性)

コレモヨクワカラナカッタ・・・。ただし、よくあるユーザの電話番号をどう持つかって話は、仕様にもよるけど自宅電話番号と携帯電話番号の2カラム用意して両方NULL可にすれば良いと思う(緊急連絡先や職場の電話番号が必要ならまた別にもつ)。どちらかの登録が必須の場合は、もうアプリケーションで制御。クライアント側とサーバ側で制御すればほぼ安全でしょ。

8章 Metadata Tribble(メタデータ大増殖)

同じデータが入るのに年度別とかにテーブルわけちゃだめだよって話。ソースの修正も必要になるよね・・・やだな。

続きはまた今度。