数据库设计：需要唯一的行+关系

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，并被许多其他表引用。

我要求每一行都是唯一的。在示例中，一行被定义为 name、invoice_price 和 msrp 列。 （不同的表可能对哪些列定义“行”有不同的定义。）

问题：

1. 在上面的示例中，我应该创建 name、invoice_price 和 msrp 一个组合键来保证每行的唯一性？
2. 如果#1 的答案是“是”，则意味着当前 PK product_id 不会被定义为密钥；相反，它只是一个自动递增的列。这足以让其他表用来创建与 product 表中特定行的关系吗？

请注意，在某些情况下，表可能有 10 个或更多需要唯一的列。这将是定义复合键的很多列！这是一件坏事吗？

我正在尝试决定是否应该尝试在数据库层或应用程序层中强制执行这种唯一性。我觉得我应该在数据库级别执行此操作，但我担心使用非键作为 FK 或让如此多的列定义复合键可能会产生意想不到的副作用。

Answer 1

当您有很多列需​​要创建唯一键时，请使用这些列中的数据作为源来创建您自己的“键”。这意味着在应用程序层创建密钥，但数据库将“强制”唯一性。一种简单的方法是使用记录的所有数据集的 md5 哈希值作为唯一密钥。然后，您只需在关系中需要使用一条数据。

md5 不能保证唯一，但它可能足以满足您的需求。

Answer 2

首先，如果您可以轻松地做到这一点，那么您在数据库层中执行此操作的直觉是正确的。这意味着即使您的应用程序逻辑发生变化，您的数据库约束仍然有效，从而降低了出现错误的机会。

但是，您确定想要独一无二吗？我可以很容易地看到同一个小部件有不同的价格，比如出售物品或其他物品。

我建议不要强制执行唯一性，除非有真正的理由。

你可能有这样的东西（显然，不要在生产代码中使用 * ）

# 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

Answer 3

您可以定义复合主键和唯一索引。只要满足您的要求，定义复合唯一键并不是一个糟糕的设计。显然，您添加的列越多，更新键和搜索键的过程就越慢，但如果业务需求需要这样做，我不认为这是负面的，因为他们有非常优化的例程来执行这些操作。