DDLレベルの外部キー制約は不要 - 設計者の発言
テーブルを作る際に、DDLレベルで外部キー制約をつけることがあるが、私はこれには反対である。組み込める制約の幅が狭すぎるうえに、業務ルールに関する記述があちこちに散らばってしまうからだ。順を追って説明しよう。 外部キー制約を組み込むことで、テーブルは更新・追加・削除操作において制約を受ける。たとえば、受注テーブルが顧客idを持っているとして、これに顧客マスターに対する外部キー制約を与えるとしよう。このとき、受注登録の際に顧客idの値がその時点の顧客マスター上に定義されていなければエラーになる。また、特定の顧客データを顧客テーブルから削除しようとしたときに、既存の受注データと関連づけされているような顧客であれば、やはりエラーになる。 この程度の例であれば、外部キー制約をDDLレベルで組み込むことに何ら問題はない。 ところが、現実は想像以上に複雑である。たとえば、多少不自然な例ではあるが、受注
ＳＩ企業が「モデルシステム」を公開しない理由 - 設計者の発言
誰もが参照できる「モデルシステム」がシステム開発業界には必要だ。そんな「知的社会資本」の整備は、この業界が長い間ないがしろにしてきた社会的使命である――私のこの主張に対して非現実的だと言われることがある。曰く、その種のノウハウは開発事業における競争力の源泉みたいなものだから、そんなものを積極的に公開しようとするお人好しな開発企業なんてあるはずがない、と。 モデルシステムは建築業界における「モデルハウス」に相当する。業種別の設計情報やその実装版としてライブラリ化されたもののことを言う。これを叩き台として個別案件が開始されるようになれば、システム開発のスタイルは一変する。なにしろ「作り始める前に完成している」のだから。 そういうリソースをシステム開発企業が積極的に公開するとは私も思っていない。しかしその理由として「システム開発業における競争力の源泉だから公開するはずがない」などと解説されると不
サロゲートキーは強制されるべきものではない - 設計者の発言
複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
