■SQLアンチパターンをコピペするアンチパターン

キーレスエントリー(外部キー嫌い)

外部キー嫌いがアンチパターンなのは同意だが、間違った外部キーの使い方するほうがよっぽどアンチパターンじゃないか？

外部キー貼らなかったことによって、俺はこんな被害だしたぜっての是非教えてほしい。

すぐに思いついたケースは

• 流通配送システムなんかで、注文受付後、配送前にユーザーが退会したから配達先の住所がわからない（*_*）

とかを思いついたがこんなケースで合ってるのか？こんなケースより間違った外部キーの使い方したほうが家に帰れなくなるケースのほうが多いと思うぞ。間違った使い方をしていて、システムが太ってくるとこんなケースが出てくる。

• テーブルが太ってきたからパーティションシャーディングしたいけど、外部キー制約でパーティションできなくて帰れない（*_*）
• SQLアンチパターンの通り、on delete cascade または set defaultを指定していたら、ユーザが退会したタイミングで決済伝票が行方不明になっちゃって帰れない(*_*)
• いっぱいtweetしている複数人のユーザが一度に退会したらマルチスレッドで大量のIOが発生して帰れない（*_*）

特に下2つは害悪で、SQLアンチパターンをコピペして、「おまえらw外部キー嫌いはアンチパターンだぞwww」ってやるのもいいけど、同じくらい間違った使い方を注意喚起したほうがいいと思うよ。DB識者のなかでは「そんなの常識w」かもしれないが何もしらない初心者が真似をしてお家に帰れなくなるのは辛くないか？

そんな経験していると、DB初心者は「せや！ユーザテーブルに退会フラグか論理削除フラグ持ったろwww　うはw俺天才www」とかなって今度は削除フラグ持つなおじさんが出てくるぞ。しまいにはこれですよ。

http://b.hatena.ne.jp/entry/s/qiita.com/ponkotuy/items/6049388d564fb4385f4e

初心者どうしたらいいんでしょうね(*_*) 是非、DB識者には明るい未来を示して欲しいね。

俺？俺はAndroidのエンジニアでSQLiteは使わないから関係ないね。

RDB初心者の俺が恐れ多くも案を出すと、FKを作成する前に、そのテーブルの性質を予測することが大事なんじゃないかね？大量に発生するログデータなのか、大事なトランザクションデータなのか、第2正規化しただけのただの情報テーブルなのか。大事なトランザクションデータだったら親が削除された時にどこにどうやって退避するか。大量のログデータだったら、親が削除される時どうアプローチするか。とか恐れ多くも予測するね。

ちなみに外部キーないからER図出せないってのはそれはツールの作りであって、FK制約とは関係ないんじゃないの。バリデーション(外部キー)はセキュリティ対策(ER図を作成する)の為、実装するってのと個人的に同じことだと思っている。

だから先ずは外部キーを使用していなくて「こんな被害を出した」ってのを聞いてみたい。

Permalink | 記事への反応(3) | 09:47

ツイートシェア