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