Crea un vincolo univoco con colonne null

Ho una tabella con questo layout:

CREATE TABLE Favorites
(
  FavoriteId uuid NOT NULL PRIMARY KEY,
  UserId uuid NOT NULL,
  RecipeId uuid NOT NULL,
  MenuId uuid
)

Voglio creare un vincolo unico simile a questo:

ALTER TABLE Favorites
ADD CONSTRAINT Favorites_UniqueFavorite UNIQUE(UserId, MenuId, RecipeId);

Tuttavia, ciò consentirà più righe con lo stesso (UserId, RecipeId), se MenuId IS NULL. Voglio permettere NULLa MenuIdmemorizzare un favorito quel menu non ha alcun associato, ma voglio solo al massimo una di queste righe per coppia utente / ricetta.

Le idee che ho finora sono:

1. Usa un UUID hardcoded (come tutti gli zeri) invece di null.
   Tuttavia, MenuIdha un vincolo FK nei menu di ogni utente, quindi dovrei creare uno speciale menu "null" per ogni utente che è una seccatura.

2. Verificare l'esistenza di una voce null utilizzando invece un trigger.
   Penso che questa sia una seccatura e mi piace evitare i trigger laddove possibile. Inoltre, non mi fido di loro per garantire che i miei dati non siano mai in cattivo stato.

3. Basta dimenticarsene e verificare l'esistenza precedente di una voce null nel middleware o in una funzione di inserimento e non avere questo vincolo.

Sto usando Postgres 9.0.

C'è qualche metodo che sto trascurando?

Crea due indici parziali :

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;

In questo modo, può esserci solo una combinazione di (user_id, recipe_id)dove menu_id IS NULL, implementare efficacemente il vincolo desiderato.

Possibili inconvenienti: non è possibile fare riferimento a una chiave esterna (user_id, menu_id, recipe_id), non è possibile basarsi CLUSTERsu un indice parziale e le query senza una WHEREcondizione corrispondente non possono utilizzare l'indice parziale. (Sembra improbabile che tu voglia un riferimento FK largo tre colonne - usa invece la colonna PK).

Se è necessario un indice completo , è possibile in alternativa eliminare la WHEREcondizione favo_3col_uni_idxe i requisiti verranno comunque applicati.
L'indice, che comprende ora l'intero tavolo, si sovrappone all'altro e diventa più grande. A seconda delle query tipiche e della percentuale di NULLvalori, questo può o non può essere utile. In situazioni estreme potrebbe anche aiutare a mantenere tutti e tre gli indici (i due parziali e un totale in cima).

A parte: consiglio di non usare identificatori di casi misti in PostgreSQL .

È possibile creare un indice univoco con una coalescenza nel MenuId:

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

Dovresti solo scegliere un UUID per la COALESCE che non si verificherà mai nella "vita reale". Probabilmente non vedresti mai un UUID zero nella vita reale ma potresti aggiungere un vincolo CHECK se sei paranoico (e dal momento che sono davvero pronti a prenderti ...):

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

È possibile memorizzare i preferiti senza menu associato in una tabella separata:

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

Penso che ci sia un problema semantico qui. A mio avviso, un utente può avere una (ma solo una ) ricetta preferita per preparare un menu specifico. (L'OP ha menu e ricette confusi; in caso di errore: scambiare MenuId e RecipeId di seguito) Ciò implica che {utente, menu} dovrebbe essere una chiave univoca in questa tabella. E dovrebbe puntare esattamente a una ricetta. Se l'utente non ha una ricetta preferita per questo menu specifico, non dovrebbe esistere alcuna riga per questa coppia di chiavi {user, menu}. Inoltre: la chiave surrogata (FaVouRiteId) è superflua: le chiavi primarie composite sono perfettamente valide per le tabelle di mappatura relazionale.

Ciò porterebbe alla definizione ridotta della tabella:

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)
);