参照整合性制約 - 高温処理済みコースケ

今日、DBのForeign keyの話題があった。みんなあんまり好きじゃないよね。これ。
おれも一時期嫌いな時期があったんだけど、最近は嫌いではなくなった。

理由は多分DBとは常に集合演算というのを頭に入れれたことだとおもう。そのきっかけは多分この記事で、この記事を読んで以来RDBというかSQLが好きになったからだ。

それまでははっきりいうとRDBとはOR Mapperで、標準の決まらない使いにくいうっとおしい奴と同義だった。それはOR MapperであってRDBとは何の関係もないのだが、やはりあまり好きではなかった。

まあ好きといっても入れ込んでいるわけではないが、麻雀の手配が聴牌しているか、とか何向聴かとかをSQLで書いてみたりした。

で話をもどすと、いま久しぶりにRDBをつかった開発をしている。まあ正確にいうと僕のメインではないのだけれど、まあ必要なデータとかは自分で入れるしといったところだ。

ただ以前と違うところは、最近データをいれるときにちゃんとSQL文を書いていて、しかもinsert - selectで書いている。insert - selectでForeign keyのあるテーブルとjoinしてinsertすれば、参照整合性制約って絶対にひっかからない。

テーブルX,YがMany-Manyの関係を構成する為の関連テーブルA(X-A-Y)にx1とy1のマッピングを追加するときも次のように書く

insert into A (x_id,y_id,someday)
  select X.id,Y.id,now() 
  from X,Y 
  where x.id = 'x1' and y.id='y1'

X,Yに実は元データがなかったということはたまに更新0件ってなると、SQLが間違ってたか、データがなかったのかでちょっとビックリするけど、慣れれば全然苦じゃないし、最近はむしろvaluesをつかって入れることができる場合のほうが稀とおもってきた。

昔なら多分このように書いていて

insert into A 
  (x_id,y_id,someday) 
  values('x1','y1',now());

たまに参照整合性制約に引っかかって、ウザって思ってた気がする。

長くなってしまったが、何がいいたいかというと開発のときこそ必要なものだろってことだ。きっと。