列がnullの一意制約を作成する

このレイアウトのテーブルがあります：

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つだけが必要です。

私のこれまでの考えは次のとおりです。

1. nullではなく、ハードコードされたUUID（すべてゼロなど）を使用します。
   ただし、MenuId各ユーザーのメニューにはFK制約があるため、ユーザーごとに特別な「null」メニューを作成する必要があり、面倒です。

2. 代わりにトリガーを使用して、nullエントリの存在を確認してください。
   これは面倒で、トリガーをできるだけ避けたいと思います。加えて、私は彼らが私のデータが決して悪い状態にあることを保証することを信頼していません。

3. それを忘れて、ミドルウェアまたは挿入関数にnullエントリが以前に存在するかどうかを確認してください。この制約はありません。

Postgres 9.0を使用しています。

私が見落としている方法はありますか？

2つの部分インデックスを作成します。

CREATE UNIQUE INDEX favo_3col_uni_idx ON favorites (user_id, menu_id, recipe_id)
WHERE menu_id IS NOT NULL;

CREATE UNIQUE INDEX favo_2col_uni_idx ON favorites (user_id, recipe_id)
WHERE menu_id IS NULL;

この方法で(user_id, recipe_id)はmenu_id IS NULL、whereの組み合わせは1つしかなく、目的の制約を効果的に実装できます。

考えられる欠点：外部キー参照(user_id, menu_id, recipe_id)を使用できずCLUSTER、部分インデックスに基づくことができず、一致WHERE条件のないクエリでは部分インデックスを使用できません。（3列幅のFK参照が必要になる可能性は低いようです。代わりにPK列を使用してください）。

完全なインデックスが必要な場合は、代わりにWHERE条件を削除しfavo_3col_uni_idxても、要件は引き続き適用されます。
インデックスはテーブル全体で構成され、他のインデックスと重複して大きくなります。一般的なクエリとNULL値のパーセンテージによっては、これが役立つ場合と役に立たない場合があります。極端な状況では、3つすべてのインデックス（2つの部分的なインデックスと全体のインデックス）を維持することも役立つ場合があります。

余談ですが、PostgreSQLでは大文字と小文字が混在する識別子を使用しないことをお勧めします。

MenuIdに合体した一意のインデックスを作成できます。

CREATE UNIQUE INDEX
Favorites_UniqueFavorite ON Favorites
(UserId, COALESCE(MenuId, '00000000-0000-0000-0000-000000000000'), RecipeId);

「実生活」では決して発生しないCOALESCEのUUIDを選択するだけで済みます。実生活ではおそらくUUIDがゼロになることはないでしょうが、偏執的である場合はCHECK制約を追加できます（そして、それらは本当にあなたを取得するために外出しているためです...）：

alter table Favorites
add constraint check
(MenuId <> '00000000-0000-0000-0000-000000000000')

メニューが関連付けられていないお気に入りを別のテーブルに保存できます。

CREATE TABLE FavoriteWithoutMenu
(
  FavoriteWithoutMenuId uuid NOT NULL, --Primary key
  UserId uuid NOT NULL,
  RecipeId uuid NOT NULL,
  UNIQUE KEY (UserId, RecipeId)
)

ここには意味上の問題があると思います。私の見解では、ユーザーは特定のメニューを準備するためのお気に入りのレシピ（1つのみ）を持つことができます。（OPにはメニューとレシピが混在しています。間違っている場合は、以下のMenuIdとRecipeIdを入れ替えてください）これは、{user、menu}がこのテーブルの一意のキーであることを意味します。そして、それは正確に1つのレシピを指す必要があります。ユーザーがこの特定のメニューのお気に入りのレシピを持っていない場合、この{user、menu}キーペアの行は存在しないはずです。また、代理キー（FaVouRiteId）は不要です。リレーショナルマッピングテーブルでは、複合主キーが完全に有効です。

これにより、テーブルの定義が削減されます。

CREATE TABLE Favorites
( UserId uuid NOT NULL REFERENCES users(id)
, MenuId uuid NOT NULL REFERENCES menus(id)
, RecipeId uuid NOT NULL REFERENCES recipes(id)
, PRIMARY KEY (UserId, MenuId)
);