存储来自多个商店的产品价格

Question

我正在开发一个可以比较多家商店的产品价格的网络服务。

我想到了以下数据库设计（简化）：

Store:
- id PK
- name
- url

Product:
- id PK
- name

ProductPricing:
- productUrl PK
- store
- price
- date
- discount

没有理想的世界，因此来自不同商店的产品可能会有所不同/ex。产品名称可能拼写不同或包含一些其他字符（例如 IV 而不是 4）/。这就是我决定使用 URL 作为Pricing 表主键的原因。

定价按产品分组（有名称和其他一些属性）。从商店 API 插入产品定价时，会按名称检查此类产品是否存在于数据库中（经过一些字符串清理后）。如果没有此类产品，则正在创建新产品。

我想知道这是否是最好的方法？如果任何商店将更改其 URL 结构怎么办？这样的数据库设计是否足够高效？

更新 @Gordon Linoff 提出了一系列非常好的问题。一些答案和说明可以在下面找到。

应用程序中产品的主要属性是什么？绝对是产品名称。将产品名称存储为主键的关键问题是商店之间的名称不同/在插入新产品之前，有一个内部服务可以修复应用程序中的名称/。

该应用程序的关键功能是识别不同商店的不同产品。第二个关键特征是产品与多个商店的价格/定价历史之间的联系/这就是为什么将 URL 作为主键理念诞生的原因/。

用户会如何看待价格？
有趣的问题。会有一个产品列表，带有产品名称/和一些其他属性/。在单个视图中，将有一个跨不同商店的价格列表。就是这样。

另一方面，产品价格将每天更新一次。如果任何 URL 发生变化，应用程序将尝试根据产品名称插入定价。如果在Product 表/ 中有一个数据库行，应用程序将使用新的Pricing 项连接找到的Product。因此，如果任何商店更改其 URL 结构，应用程序不应受到影响。我错过了什么吗？

也许我应该将 URL 作为常规属性 /column 存储在数据库中，而不是将其用作主键/？

Answer 1

评论太长了。

使用远程控制的 URL 作为产品的主键似乎是一个非常糟糕的主意。您无法控制 URL。而且，这些事情的变化不是一声呜咽，而是一声巨响——突然之间，给定网站的所有 URL 都会发生变化。

您需要改变设计的视角。 用户将如何看待价格？他们将如何描述产品？在不同站点上识别完全相同的产品是否重要？这些是您需要围绕这些进行设计的关键属性。

您可能需要设计自己的基础架构来识别产品。您也许可以使用每个供应商的方案（这些方案通常以 SKU 为单位——库存单位）。或者，您可能有使用诸如 UPC（通用产品代码）之类的行业标准方法。