タグ付けされた質問 「referential-integrity」

私は聞いた覚えジョエル・スポルスキの中で言及をポッドキャスト014（私は記憶が正しければ）彼はやっと今までに外部キーを使用したいということ。しかし、私にとっては、データベース全体で重複やそれに続くデータの整合性の問題を回避するために非常に重要なようです。 理由については、確かな理由がありますか（スタックオーバーフローの原則に沿った議論を避けるため）。 編集： 「外部キーを作成する理由がまだないので、実際に設定するのはこれが最初の理由かもしれません。」

259 database  database-design  foreign-keys  referential-integrity  data-integrity 

このレイアウトのテーブルがあります： CREATE TABLE Favorites ( FavoriteId uuid NOT NULL PRIMARY KEY, UserId uuid NOT NULL, RecipeId uuid NOT NULL, MenuId uuid ) 次のような一意の制約を作成します。 ALTER TABLE Favorites ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId); ただし、これにより、同じ(UserId, RecipeId)場合に複数の行が許可されますMenuId IS NULL。メニューが関連付けられていないお気に入りを保存できるようNULLにMenuIdしたいのですが、ユーザー/レシピのペアごとにこれらの行の最大1つだけが必要です。 私のこれまでの考えは次のとおりです。 nullではなく、ハードコードされたUUID（すべてゼロなど）を使用します。 ただし、MenuId各ユーザーのメニューにはFK制約があるため、ユーザーごとに特別な「null」メニューを作成する必要があり、面倒です。 代わりにトリガーを使用して、nullエントリの存在を確認してください。 これは面倒で、トリガーをできるだけ避けたいと思います。加えて、私は彼らが私のデータが決して悪い状態にあることを保証することを信頼していません。 それを忘れて、ミドルウェアまたは挿入関数にnullエントリが以前に存在するかどうかを確認してください。この制約はありません。 Postgres 9.0を使用しています。 私が見落としている方法はありますか？

252 sql  postgresql  database-design  null  referential-integrity