テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるうえに、業務ルールに関する記述があちこちに散らばってしまうからだ。順を追って説明しよう。 外部キー制約を組み込むことで、テーブルは更新・追加・削除操作において制約を受ける。たとえば、受注テーブルが顧客idを持っているとして、これに顧客マスターに対する外部キー制約を与えるとしよう。このとき、受注登録の際に顧客idの値がその時点の顧客マスター上に定義されていなければエラーになる。また、特定の顧客データを顧客テーブルから削除しようとしたときに、既存の受注データと関連づけされているような顧客であれば、やはりエラーになる。 この程度の例であれば、外部キー制約をDDLレベルで組み込むことに何ら問題はない。 ところが、現実は想像以上に複雑である。たとえば、多少不自然な例ではあるが、受注
PostgreSQL の SQL を静的に構文チェックしたくて、調べていたら pgsanity というぴったりなプログラムがあったので、使い方を簡単にメモ SQL の構文チェック SQL を実際に実行せずに、SQL の構文だけをチェックしたい場合 explain を走らせる テーブルがなにもない空のデータベースに対して実行する トランザクションで SQL を囲み、最後にアボートする とった方法がある。 出来ればデータベースを介さずに SQL の構文をチェックしたいなぁと探していると pgsanity というのがあった。 pgsanity のアーキテクチャ PostgreSQL には SQL を C 言語のプログラム内にインラインで記述する埋め込み SQL(embedded SQL) の機能がある。 埋め込み SQL のメリットとしては、マニュアル(§33.1 The Concept)では以
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く