Question

这是机票在线商店的数据库（例如Airbnb体验）

对于产品（门票），

有可用的日期（和时间）

在可用的一天，
-可能有多个选项（例如，初学者，高级）
-有数量可以出售（在多个选项中共享）

一种表示方法是

Product
  name

Variant (Option)
  product

TimeSlot
  product
  date
  time
  quantity


TimeslotVariant
  variant
  timeslot

另一种方法如下。

我看到两个主要区别，

第一个区别
- 以上：您需要加入TimeSlot才能找到给定日期的变体。
- 以下：您可以直接查询TimeVariant
二阶差异
- 上面：[{date, time, [variant1, variant2], quantity}]（我认为客户端应用程序会更喜欢）
- 以下：[{date, time, variant1}, {date, time, variant2}] + [{date, time, quantity}]

Product
  name

Variant (Option)
  product


TimeSlot
  product
  date
  time
  quantity

TimeVariant
  variant
  date
  time

我认为第一个选项更直观（？），但我也认为有时无法进行额外的联接

我应该问自己哪些问题（标准），以决定两者？

Answer 1

恕我直言，连接数可能不是设计关系数据库时需要问自己的最重要问题。

最重要的问题是如何确保保护数据完整性。最好使用您提出的第一个选项来保持数据完整性，所以这是您应该选择的选项。

如果让您困扰的是联接，您可以随时使用视图来“拉平”数据。

但是为什么第一个选择更好？由于TimeSlot表的主键（或至少是自然键）必须由product，date和time组成-第二个选项不需要在TimeVariant表中考虑产品。

您也可以在该表中添加product，一些DBA会建议将其作为最佳选择（那些是反对使用代理键的DBA）-但就我个人而言，即使我我自己不是DBA，我认为代理键具有它的优点，而其中一个正是您所拥有的-您可以使用单列而不是三列来连接两个表-这使您的工作变得更加轻松（并具有唯一性）表的自然键中，代理键没有完整性问题。

Answer 2

首先，您应该考虑是否要减少加盟费用？如果是，则可以使用存储在视图中的扁平化数据。

首例

在 TimeslotVariant 中，您已经添加了 variant 和 timeslot ，只有通过查询TimeslotVariant表，您才能获得预期的数据。在这种情况下，您的数据完整性就可以了。

第二种情况

如果将产品密钥添加到TimeslotVariant，则仅显示产品清单即可达到目的，尽管时间和日期也会重新输入。

我的建议是保留第一种情况并将扁平化数据存储在视图中。

数据库设计，减少联接

2 个答案: