Створіть унікальне обмеження з нульовими стовпцями

У мене є таблиця з такою компоновкою:

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. Використовуйте кілька жорстко закодованих UUID (таких як усі нулі) замість null.
   Однак MenuIdу меню кожного користувача є обмеження FK, тому мені доведеться створити спеціальне меню "null" для кожного користувача, який є клопотом.

2. Перевірте наявність нульового запису за допомогою тригера.
   Я думаю, що це клопоту, і мені подобається уникати тригерів, де це можливо. Плюс, я не вірю їм, щоб гарантувати, що мої дані ніколи не знаходяться в поганому стані.

3. Просто забудьте про це і перевірте наявність попереднього запису в середньому посуді або в функції вставки, і не мати цього обмеження.

Я використовую Postgres 9.0.

Чи є якийсь метод, який я не помічаю?

Створіть два часткові індекси :

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, ефективно реалізуючи бажане обмеження.

Можливі недоліки: у вас не може бути посилання на іноземний ключ (user_id, menu_id, recipe_id), ви не можете базуватися CLUSTERна частковому індексі, а запити без відповідного WHEREумови не можуть використовувати частковий індекс. (Мабуть, ви хочете, щоб ви хотіли, щоб FK посилалось на три колонки - замість цього використовуйте стовпець ПК).

Якщо вам потрібен повний індекс, ви можете відмовитись від WHEREумови, favo_3col_uni_idxі ваші вимоги все ще виконуються.
Індекс, який зараз складається з усієї таблиці, перекривається з іншою і збільшується. Залежно від типових запитів і відсотківNULL значень, це може бути або не корисно. В екстремальних ситуаціях це може навіть допомогти зберегти всі три індекси (два часткові та загальний верх).

Убік: Я раджу не використовувати змішані ідентифікатори регістрів у PostgreSQL .

Ви можете створити унікальний індекс з коалесценцією в MenuId:

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

Вам просто потрібно вибрати UUID для COALESCE, який ніколи не відбудеться в "реальному житті". Ви, мабуть, ніколи не бачите нульового UUID у реальному житті, але ви можете додати обмеження ПЕРЕВІРИТИ, якщо ви параноїчні (а оскільки вони насправді виходять, щоб отримати вас ...):

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

Я думаю, тут є семантична проблема. На мій погляд, у користувача може бути (але лише один ) улюблений рецепт для підготовки конкретного меню. (У OP є меню та рецепти змішані; якщо я помиляюся: будь ласка, замініть MenuId та RecipeId нижче) Це означає, що {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)
);