对不起标题，我找不到更好的。欢迎提出建议。
假设我们有两个表，Suppliers并且Products. 相同的产品可能来自许多不同的供应商，因此我们SuppliersAndProducts使用此模式创建第三个表，我们称之为
SuppliersAndProducts
- id (autoincrement)
- supplier_id
- product_id
- from_date
- to_date
from_并且to_date可以解释这样一个事实，即给定的供应商可能会停止销售给定的产品，但也可能在未来的某个时候再次开始销售。
现在，我们要存储Product从给定的购买 a 时支付的价格Supplier。当然，价格会随着时间而变化，我们也希望对其进行跟踪。
所以我们引入一个表，我们称之为SuppliersAndPrices，结构如下：
SuppliersAndPrices
- id (autoincrement)
- supplier_id (FK to the supplier id)
- product_id (FK to the product id)
- price
- from_date
- to_date
我关于最后一张表的问题比其他任何问题都更具概念性：这张表是否应该像我描述的那样（意味着关联基于供应商和产品 ID），或者只是引用SuppliersAndProducts我们可以调用的列的 ID suppliers_and_products_id？
后者的设计比前者更规范化；毕竟，aSupplier和 a之间的关联Product已经在 中说明SuppliersAndProducts，因此重复该信息没有什么意义。尽管如此，至少对我来说，出于某种原因，前者感觉更接近现实世界。
从查询复杂性的角度来看，要知道我今天为给定产品支付的价格，我必须编写第一个设计（使用一些伪 SQL 以保持与数据库无关），例如：
SELECT price
FROM SuppliersAndPrices
WHERE supplier_id = X
AND product_id = Y
AND today is between from_date and to_date
而第二种设计需要连接，因此查询看起来像：
SELECT price
FROM SuppliersAndPrices
INNER JOIN SuppliersAndProducts
ON SuppliersAndPrices.suppliers_and_products_id = SuppliersAndProducts.id
WHERE SuppliersAndProducts.supplier_id = X
AND SuppliersAndProducts.product_id = Y
AND today is between SuppliersAndPrices.from_date and SuppliersAndPrices.to_date
我正在写这篇文章，对我的 SQL 感到抱歉。
另外，现在我考虑了一下，对于第二种设计，我必须在WHERE条款中添加另一个条件来检查日期SuppliersAndProducts，以处理 aSupplier将停止携带产品并在某个时候开始销售的情况再次。在那种情况下，连接条件将返回多行，这将不是一件好事™。
那么，你会选择哪一个？以更规范化的名义关联已经是关联的 id，但以增加查询复杂性为代价？去规范化一点点以使查询更容易，并且可以说，数据库结构对于未来的维护者来说更清晰？
第二种设计的查询可能隐藏在视图后面，但那仍然是必须维护和理解的代码。对于“更好”的某些定义，我真正想知道的是两种设计中哪一种“更好”。
只是为了解决这部分问题，保留历史数据的目的是什么？如果应用程序允许用户在某种程度上进行交互，那么可以，因为这仍然是一种交易需求。否则，如果它仅用于报告目的，则可以在单独的服务器/数据库/模式中完全跟踪，因为您实际上是在谈论缓慢变化的维度 (SCD)。如果它仅用于报告，则无需使用当前信息以外的任何东西使您的交易模型复杂化。
话虽如此，我假设交易目的需要数据，在这种情况下毫无疑问（在我看来，至少 :) 选项 2（即将价格信息与供应商和产品关系表相关联）是唯一的出路。如果您将 Price 属性与其各自的来源相关联，则您允许 SuppliersAndProducts 表中不存在的 Suppliers 和 Products 的无效组合。虽然性能和可维护性是设计时非常重要的考虑因素，但它们仅次于数据完整性，因为这是数据库的主要职责。
一些注意事项：
最好使用表名+“id”而不是通用的“id”。这将使编写查询更容易，因为表之间的字段名称相同。一般来说，查询将更具可读性。
虽然我也喜欢将表格命名为复数（这样听起来更好），但它确实让使用单数变得更容易。这样，表的“id”字段包含表名而不奇怪，例如“SuppliersID”（与“SupplierID”相反）。如果您必须针对表编写自动化流程代码，则假设 ID 字段只是“{TableName}ID”会容易得多，否则您可能需要访问数据库进行查找。对于接受培训的新人来说，更容易知道任何表都会有一个标准的 ID 字段名称，这使得编写查询更快。这就是我不再使用复数表名的原因:)。因此，例如，
SuppliersAndProduct将是SupplierAndProduct，甚至可能是SupplierXProduct。如果不是历史值，那么
SupplierAndProduct就不需要自动递增的 ID，因为 和 的组合SupplierID将ProductID是复合 PK。但是因为我们确实有那个历史，我们可以用那个关系表做两件事：
SupplierAndProductID领域SupplierAndProductID、SupplierID和ProductID字段组合的唯一索引（表示“备用键”）对于我们将拥有的
SupplierAndProductPrice（或SupplierXProductPrice）表（仅就此处的关键字段而言；“价格”和日期等字段没有变化）：在此模型中，由于 supplier_and_product_id 字段没有任何实际意义，我们将其他两个字段一起带入，所有 3 个字段的组合将返回到 supplier_and_product 的唯一索引。我通常会尽量避免 FKs 到唯一索引/约束，但在这种情况下这样做是有意义的。
将所有 3 个字段放在一个唯一索引中以便将 FK 引用到它允许引入两个需要的字段（
supplier_id和product_id），同时保证这两个的组合始终是有效组合（因为它由 FK 强制执行） .我建议不要将这些合并到一个表中，因为当价格在产品与供应商关系的日期和日期发生变化时，它会复制产品和供应商的关系信息。但是，这仅适用于交易方面。在报告方面，按照@JonofAllTrades 的建议将它们结合起来绝对是个好主意。
fromto关于需要额外的 WHERE 条件来检查日期与中的日期
from和to日期supplier_and_product：这不是一个坏主意，但在技术上只是一个安全措施，假设该应用程序不允许给定的价格条目有下降的日期在该供应商供应产品的时间范围之外。但是，如果日期在某种程度上验证了这种奇怪的情况，那么您现在可以摆脱选项 1 的简化查询（因为和字段在那里），同时具有选项 2 的完整性（因为这些字段也 FK 回到关系表). 这意味着您真的应该 FK 中的和字段product_idsupplier_idsupplier_and_productproduct_idsupplier_idPrice将表返回到关系表及其各自的父表，因为这将有助于Price两个父表之间的 JOIN。我会把两者结合起来。添加
Price到您的SuppliersAndProducts表格（也可能称它为其他名称，例如Catalog或Offerings），当价格变化时结束第一条记录并开始另一条记录。PK on
CatalogID, biz key on {SupplierID,ProductID,EffectiveDate}。为了比较。在我见过的大多数类似销售的数据库中，价格仅存储在
OrderDetails表中，这仍然更简单，但如果您没有从特定供应商处订购产品，显然不能让您获得该产品的历史价格相关的日期范围。为了说明 srutsky 关于粒度的观点：该模型将创建比 OP 的第二个模型更多的供应商/产品记录，后者的价格从产品销售时开始在单独的表中进行跟踪。如果我们从一个简单的例子开始，我的模型会更简单；如果一个产品有两个供应商，那就是两条记录：
...而另一个模型有四个记录：
但是，一旦价格开始变化，我的模型会在其（唯一）表中产生更多记录。假设两家供应商都为假期提供 25% 的折扣，然后将其恢复：
...对比：
在
Offerings+Pricing模型中，只有Pricing表在价格变化时增长。该Offerings表没有，因此不需要定价的查询不会增加额外的行。查询Offerings非常干净，代价是查询Pricing更复杂。对于这个例子，差别很小。但是，如果产品有更多属性，如制造商的 SKU 或信用条款，则单个
Catalog表将获得更多行和更多列。如果供应商更改了他们的 SKU，那就是一个新记录；如果他们在一个月后更改条款，那将是另一个新记录。在极端情况下，它可能会达到某些属性每天都在变化的地步，并且您的Catalog表格会退化为“在这一天对于这个供应商、这个产品来说是真实的”。现在，这只是在属性
Catalog易变的范围内的问题。我怀疑，在实践中，供应商的价格、SKU 和条款很少每年更改一次或两次以上，因此我们谈论的是数万行，而不是数百万行。人们需要更多地了解您的行业、您的产品和供应商基础的规模，以及您可能想要的其他属性类型，才能做出肯定的判断。Srutsky 的模型会更好地扩展，所以如果你有远大的想法，那才是正确的道路。如果您的需求是小规模甚至中等规模的，我怀疑您最好保持简单。