代码之家 › 专栏 › 技术社区 › Mohamad

使用以下两种数据库模式的缺点和优点是什么

database-design

Mohamad · 技术社区 · 15 年前

假设您有一家租赁电影的公司,并且您正在为您的数据库设计一个模式。客户必须选择计划、交付类型和计费期限(每月、每三个月、每六个月)。该计划有一个基本价格,并决定每个客户每月可以租多少部电影,以及一次可以租多少部。交货类型将根据客户的选择更改价格(定期交货将为计划价格增加一定的价值,快速交货将增加更高的价值)。在plans表或customers表中存储交货类型和帐单条款信息更好吗?

billingTerms(id, billEveryXMonths, discount)
deliveryTypes(id, type, price)

方法一:

plans(id, name, price, billingTermsId, deliveryTypeId, monthlyLimit, atHomeLimit)
customers(id, name, planId)

方法二是在customer表中存储计划id、交付类型和计费条件:

plans(id, name, price)
customers(id, name, planId, billingTermId, deliveryTypeId)

此外,monthlyLimit和atHomeLimit必须链接到一个控件表,该控件表跟踪每个月的客户活动。

4 回复 | 直到 15 年前

Jeremy Goodell 15 年前

您希望使您的数据库模式尽可能接近“真实世界”。因此,在本例中,由于交付类型和帐单条款与单个客户关联,而不是与计划关联,因此您可以将它们包含在customers表中。

我不知道你为什么要考虑将类型和术语放入计划记录中,但是你说“这种方法简单得多”。你能详细说明一下你的意思吗?对我来说,这似乎更让人困惑。原因如下:

假设您为客户提供了五种不同的计划,那么相应地,您的计划表中就有五种计划。当您要创建任何类型的数据输入屏幕时,您只需从数据库中调出您的计划选项并显示它们。如果以后您决定添加一个新的计划,您可以将它添加到数据库中,如果您的视图代码编写正确,它就可以正常工作。

但是,如果要在计划表中包含所有排列,则不能使用此方法,必须在演示屏幕上对计划进行硬编码,然后在添加新计划时对其进行修改。

另外,如果将术语和类型与计划分开,则可以创建过程来修改客户,而不必修改客户对计划的选择。这自然是正确的做法,因为在这种情况下,客户没有修改他们的计划选择。

希望这有意义。

Adam Musch 15 年前

每个属性的函数依赖关系是什么?

如果不管计划如何,每个客户都可以有不同的帐单期限,那么帐单期限取决于客户,并且应该是客户表的一个属性。

但是,如果每个计划都有一个默认的计费期限,但可以逐个客户覆盖它,那么有两个选择:

有一个关联实体Customer\u X\u Plan(Customer\u id(pk)、Plan\u id(pk)、billing\u term\u id),您可以在其中存储每个客户与其计划相关的属性的正确信息。

每一个都有权衡;这就是为什么它是设计而不是工程。

Steven A. Lowe 15 年前

计划和客户是不同的实体。作为一个客户,我可能想要一个计划给我,另一个计划给我的孩子。

正常化。

nvogel 15 年前

可能您产生怀疑的原因是您没有在每种情况下确定键和依赖项。一般来说,这样做是个好主意,因为确保您的表至少是BCNF/5th范式,这将立即解决许多设计问题。