Дизайн базы данных: нужны уникальные строки + отношения

Question

Скажите, у меня есть следующая таблица:

TABLE: product
============================================================
| product_id | name         | invoice_price | msrp         |
------------------------------------------------------------
| 1          | Widget 1     | 10.00         | 15.00        |
------------------------------------------------------------
| 2          | Widget 2     | 8.00          | 12.00        |
------------------------------------------------------------

В этой модели product_id - это PK, на который ссылается ряд других таблиц.

У меня есть требование, чтобы каждая строка была уникальной. В примере about строка определена как столбцы name, invoice_price и msrp. (В разных таблицах могут быть разные определения того, какие столбцы определяют «строку».)

Вопросы:

1. В приведенном выше примере, я должен сделать name, invoice_price и msrp составным ключом, чтобы гарантировать уникальность каждой строки?
2. Если ответ на вопрос № 1 «да», это будет означать, что текущий PK, product_id, не будет определяться как ключ; скорее это был бы просто автоинкрементный столбец. Будет ли этого достаточно для использования другими таблицами для создания связей с конкретными строками в таблице product?

Обратите внимание, что в некоторых случаях таблица может содержать 10 или более столбцов, которые должны быть уникальными. Это будет много столбцов, определяющих составной ключ! Это плохо?

Я пытаюсь решить, следует ли мне применять такую ​​уникальность на уровне базы данных или на уровне приложения. Я чувствую, что должен делать это на уровне базы данных, но я обеспокоен тем, что могут быть непреднамеренные побочные эффекты использования неключевого ключа в качестве FK или наличия большого количества столбцов, определяющих составной ключ.

Answer 1

Вы можете определить составные первичные ключи, а также уникальные индексы.Пока ваше требование выполнено, определение составных уникальных ключей не является плохим дизайном.Понятно, что чем больше столбцов вы добавляете, тем медленнее происходит процесс обновления ключей и поиска ключей, но если это необходимо для бизнес-требований, я не думаю, что это отрицательно, поскольку они имеют очень оптимизированные подпрограммы для этого.

Answer 2

Если у вас есть много столбцов, для создания которых необходим уникальный ключ, создайте свой собственный «ключ», используя данные из столбцов в качестве источника. Это будет означать создание ключа на уровне приложения, но база данных будет «обеспечивать» уникальность. Простым методом будет использование хеша md5 всех наборов данных для записи в качестве вашего уникального ключа. Тогда у вас есть только один фрагмент данных, который нужно использовать в отношениях.

md5 не гарантированно будет уникальным, но может быть достаточно для ваших нужд.

Answer 3

Во-первых, ваша интуиция сделать это на уровне БД верна, если вы можете сделать это легко.Это означает, что даже если логика вашего приложения изменится, ограничения БД все еще действительны, что снижает вероятность ошибок.

Но вы уверены, что хотите уникальности в этом?Я мог бы легко увидеть один и тот же виджет с разными ценами, скажем, на продажу или нет.

Я бы рекомендовал не применять уникальность, если только для этого нет реальной причины.

У вас может быть что-то подобное(конечно, не используйте * в производственном коде)

# get the lowest price for an item that's currently active
select * 
from product p 
where p.name = "widget 1" # a non-primary index on product.name would be advised
  and p.active
order-by sale_price ascending 
limit 1