6

在数据库原型中，我有一组字段（如名称、描述、状态），这些字段在多个功能不同的表中是必需的。

这些字段始终具有相同的最终用户功能，用于标记、显示、搜索、过滤等。它们不是外键约束的一部分。这应该如何建模？

我可以想到以下变体：

  • 每个表都获得所有这些属性。在这种情况下，您将如何命名它们？相同，在每个表中，或带有表名前缀（如 usrName、prodName）

  • 将它们移动到表属性中，将外键添加到“核心”表中，引用 Attributes.PK

  • 如上所述，但不是外键，而是在各自的核心表中使用 Attributes.PK 作为 PK。

4

5 回答 5

8

听起来您可能将标准化的想法走得太远了。请记住，这是您减少数据冗余的想法。您的示例似乎表明您担心数据库设计的元信息中的“冗余”。

最终，user.name和的功能与和user.description不同，应该这样对待。因为，这取决于你的意思。是否只是产品/用户记录处于活动状态的指标？如果是这样，那么将其拆分到另一个表可能是有意义的。product.nameproduct.descriptionstatusstatus

使用您提供的信息，如果“活动/过期/已删除”只是数据库中状态的指示，那么我肯定会同意这样的表结构：

users            products         status
  id               id               id
  name             name             name
  description      description
  status_id        status_id

但是，如果status可以想象可以改变以表示语义上不同的东西（即，对于用户，可能是“活跃/退休/解雇”，我建议将其拆分为未来的设计证明：

user_status     product_status
  id              id
  name            name

简而言之，规范化你的数据，而不是你的数据库设计。

于 2008-10-28T00:28:39.313 回答
3

除非您跨表使用相同的名称或描述值，否则不应规范化该数据。状态类型倾向于被重用，因此，将它们标准化。例如：

order_status_types
- id
- name
- description

shipping_accounts
- id
- name
- description

orders
- order_status_type_id
- shipping_account_id

preferences
- shipping_account_id
于 2008-10-28T00:27:23.577 回答
1

规范化通常是任何关系数据库中的最佳实践（在合理范围内）。

如果您有像州这样的字段（表示一个国家/地区的州），那么像“州”这样带有（id、短名称、长名称等）的引用表可能是要走的路，那么每条记录只引用一个州需要一个 state_id 列，正如您所提到的，它是对 State 表中记录的引用。

但是，在某些情况下，不一定需要对所有数据进行规范化，因为它只会使事情复杂化，但在哪里做和不做的地方应该很明显。

希望这可以帮助。

于 2008-10-27T23:54:39.150 回答
1

我会给每个表自己的一组列，即使它们具有相同的名称并且在逻辑上相似。

如果您需要通过添加或删除其中一些列或更改它们的数据类型来更改其中一个表，那么您只能在它相关的表中执行此操作，而不是弄清楚如何使您的共享属性表复杂化.

让每个表控制自己的属性可以促进Cohesion，这是一件好事。它还避免了您关于外键去向的问题。

至于列命名，没有必要也不建议在列名上加上前缀。如果您执行的连接导致来自两个表的同名列，请使用别名来区分它们。

于 2008-10-28T00:28:53.823 回答
1

我总是给每个表一个 3 个字母的代码，然后我在所有字段名称中使用它。这样，在产品表中我有 prdname、prddescription、prdstatus，在供应商文件中我有 venname、vendescription、venstatus。当事物加入时，无需担心相同的命名字段。

当然，这些表都有一个名为plain old id的字段，而product 表将有一个名为venid 的字段，它引用vendor 表中的id 字段。在这种情况下，我没有在它上面加上 prd 前缀，因为 venid 非常有意义并且是明确的。

于 2009-10-22T22:11:44.653 回答