Boş sütunlarla benzersiz kısıtlama oluşturma

Bu düzen ile bir tablo var:

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

Buna benzer benzersiz bir kısıtlama oluşturmak istiyorum:

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

Ancak bu aynı olan birden fazla satır sağlayacaktır (UserId, RecipeId)eğer MenuId IS NULL. Ben izin vermek istediğiniz NULLyer MenuIdyok menü ilişkilendirdiği bir sık saklamak için, ama sadece kullanıcı / reçete çifti başına bu satırlardan en az birini istiyorum.

Şimdiye kadar sahip olduğum fikirler:

1. Null yerine sabit kodlanmış bir UUID (tüm sıfırlar gibi) kullanın.
   Ancak, MenuIdher kullanıcının menülerinde bir FK kısıtlaması vardır, bu yüzden bir güçlük olan her kullanıcı için özel bir "boş" menü oluşturmak zorunda kalacaktım.

2. Bunun yerine bir tetikleyici kullanarak boş bir giriş olup olmadığını kontrol edin.
   Bence bu bir güçlük ve mümkün olan yerlerde tetikleyicilerden kaçınmayı seviyorum. Ayrıca, verilerimin hiçbir zaman kötü durumda olmadığını garanti etmelerine güvenmiyorum.

3. Sadece unutun ve orta eşyada veya bir ekleme işlevinde boş bir girdinin önceki varlığını kontrol edin ve bu kısıtlamaya sahip değilsiniz.

Postgres 9.0 kullanıyorum.

Göz ardı ettiğim bir yöntem var mı?

İki kısmi dizin oluşturun :

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;

Bu şekilde, yalnızca biri kombinasyon olması (user_id, recipe_id)nerede menu_id IS NULLetkili bir şekilde istenilen sınırlamayı uygulayan,.

Olası dezavantajlar: yabancı anahtar referansınız (user_id, menu_id, recipe_id)olamaz CLUSTER, kısmi bir dizine dayandırılamaz ve eşleştirme WHEREkoşulu olmayan sorgular kısmi dizini kullanamaz. (Bir FK başvurusunun üç sütun genişliğinde olmasını istemeyebilirsiniz - bunun yerine PK sütununu kullanın).

Tam bir dizine ihtiyacınız varsa , WHEREkoşulu alternatif olarak bırakabilirsiniz favo_3col_uni_idxve gereksinimleriniz yine de uygulanır.
Şimdi tüm tabloyu içeren indeks diğeriyle çakışıyor ve büyüyor. Tipik sorgulara ve NULLdeğerlerin yüzdesine bağlı olarak , bu yararlı olabilir veya olmayabilir. Aşırı durumlarda, üç indeksin de (iki kısmi ve toplamda üstte) korunmasına yardımcı olabilir.

Bir yana: PostgreSQL'de karma vaka tanımlayıcıları kullanmamanızı tavsiye ederim .

MenuId'de birleşme ile benzersiz bir dizin oluşturabilirsiniz:

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

COALESCE için "gerçek hayatta" asla gerçekleşmeyecek bir UUID seçmeniz yeterlidir. Muhtemelen gerçek hayatta sıfır UUID görmek asla ama sen paranoyak ise bir CHECK kısıtlaması ekleyebilir (ve o zamandan beri onlar gerçekten vardır ... seni almak için):

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

İlişkili menüsü olmayan favorileri ayrı bir tabloda saklayabilirsiniz:

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

Bence burada anlamsal bir sorun var. Benim görüşüme göre, bir kullanıcının belirli bir menüyü hazırlamak için ( sadece bir tane ) favori tarifi olabilir. (OP'nin menüsü ve tarifi karışıktır; yanlışsam: lütfen MenuId ve RecipeId'i değiştirin) Bu, {user, menu} öğesinin bu tabloda benzersiz bir anahtar olması gerektiği anlamına gelir. Ve tam olarak bir tarife işaret etmelidir . Kullanıcının bu belirli menü için favori tarifi yoksa , bu {user, menu} anahtar çifti için hiçbir satır olmamalıdır . Ayrıca: yedek anahtar (FaVouRiteId) gereksizdir: bileşik birincil anahtarlar ilişkisel eşleme tabloları için mükemmel şekilde geçerlidir.

Bu, tablo tanımının azalmasına neden olur:

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