【问题标题】:Appropriate way to structure a database table? (empty columns vs. multiple tables)构造数据库表的适当方法? (空列与多个表)
【发布时间】:2011-04-10 20:43:20
【问题描述】:

假设我们有一个名为 Widget 的对象,我们可以为它构造一个数据库表。

现在,假设我们有 两组 额外的细节来描述小部件。每组数据都可以在单独的时间获得。因此,假设我们的小部件的生命周期分为三个阶段......

第 1 阶段,我们只需要一个带有名称和描述的小部件。

widgets
-------
id (PK)
name
description

第 2 阶段,我们的小部件增加了高度和重量。

widgets
-------
id (PK)
name
description
height
weight

第 3 阶段,我们的小部件获得目的地和运费。

widgets
-------
id (PK)
name
description
height
weight
destination
shipping_cost

上述模式(用于“阶段 3”)意味着处于阶段 1 或阶段 2 的小部件的数据库记录将具有 null 值

或者,我们可以构造一个永远不会有空值的模式(但父记录可能有零个、一个或两个子记录,具体取决于小部件生命周期的当前阶段):

widgets
-------
id (PK)
name
description

widget_specs
-------
id (PK)
widget_id (FK)
height
weight

widget_delivery
-------
id (PK)
widget_id (FK)
destination
shipping_cost

这些选择之一总是正确的吗?每个人都有合理的利弊吗?如果答案取决于更多变量,它们是什么?在什么条件下,一种替代方案会成为明显的首选?

接受的答案将引用该主题的现代权威来源。

编辑:我觉得这很容易引起争论,但它也是一个应该有正当利弊的话题,因此是一个权威的答案。这个问题只是一个困扰我的问题,因为我已经看到它在没有理由或考虑替代方案的情况下以两种方式完成。根据当前引领潮流的 DBA 类型,我只想知道哪个正确

【问题讨论】:

  • 只是一个观察,我打算回应“接受的答案将引用该主题的现代权威来源”这一行。真的让我失望。这是一个同伴帮助论坛,不是有偿工作,这个规定似乎对寻求免费帮助的人要求过高。当然,这只是我的看法,但我很想知道其他人是否也对此感到厌烦。
  • @Serapth +1,只是因为我是权威的,但不是很现代:)

标签: language-agnostic database-design schema relational-database schema-design


【解决方案1】:

您减轻空列的选择是创建一对一的关系,或者一个小部件可以有多个重量和交付规范?

这也意味着您必须 LEFT JOIN 到两个支持表以检查信息,其中单个表不需要任何特殊的东西(除了某些情况下的 IS/IS NOT NULL 检查)。

一对一关系是一种性能优化,但这不是您问这个问题的原因...

【讨论】:

  • 为了回答您的问题,从父窗口小部件表到子表的关系是一对一的。
【解决方案2】:

范式 (BCNF / 5NF) 通常是数据库设计最可靠的基础,除非您找到偏离它的令人信服的理由。这意味着应该首选没有空值的模式。规范化减少了冗余数据和出现异常的可能性,并最大限度地减少了设计中的内置“偏差”,使其更易于维护和扩展。

空值会使数据库上的大多数操作复杂化,并导致某些查询的结果不正确。仅在您发现某些特殊原因的设计中添加空值 - 通常这些原因与 DBMS 限制有关,这些限制不允许您在不使用空值的情况下轻松实现某些约束或其他逻辑。还要记住,每当数据库设计人员将空值添加到数据库中时,应用程序设计人员通常必须做额外的工作来删除或隐藏它们,以使最终用户受益。

您可以在 Fabian Pascal 的“数据库管理中的实际问题”一书中以及 Chris Date 的书籍以及 EFCodd、Witold Lipski 和许多其他人的论文中找到关于空值和其他与缺失数据有关的问题的广泛讨论。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-06-07
    • 2013-05-18
    • 2015-08-31
    • 2021-07-18
    • 2014-03-11
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多