ON UPDATE CASCADE
データベースにREFERENCES制約をつけまくったとき、整合性を保つためにデータが変更できなくなることがあって困っていたが、REFERENCEの連鎖更新をするSQLの指定もあるらしい。今までに読んだSQLの参考書には載っていなかった。（文献が古すぎたか？）
問題はデータベースがその機能に対応しているかどうか、だが。・・・PostgreSQLでも使えるらしい。*1検索すると「やたら処理が重くなる」みたいな相談も引っかかってきたりするけど。
PostgreSQLのマニュアルでそのあたりの説明をよく読むと、ON UPDATE CASCADEとかを使うより、REFERENCESをDEFERRABLE（延期可能）にして、（ついでに初期状態で延期にして、）制約適用が延期されたトランザクション内で処理するというのが推奨らしい。
きっちりとデータベース構造を把握しておくという観点からすると、無意識的に実行されるCASCADEの処理よりもDEFERRABLEの処理の方がよいのだろう。
今度からREFERENCES制約をつけるときはDEFERRABLEにするかどうかも設計しよう・・・
そう言えばデータベースを構築するために用意した一連のSQLで、「REFERENCES制約がややこしすぎて、テーブルを作成し終わってから後でREFERENCESを追加した*2」ことがあったが、制約適用の延期はこういう場面でも有効なのだろうか。・・・試す機会がまず無いなぁ。
