我们如何处理在表的所有记录中具有相同值的列？

Posted 2023-03-12

【中文标题】我们如何处理在表的所有记录中具有相同值的列？

【英文标题】：How do we treat a column that has the same value across ALL records of a table?

【发布时间】：2013-07-02 21:27:54

【问题描述】：

假设我有一个表格，为了简化所有的行都是关于Persons，并假设我们存储了这个人的颜色。现在让我们简化一下，我们有 100 万条记录，所有人的颜色都是白色。

现在在这种情况下，white 重复了超过 100 万次。 现在，如果我们不能将表格更改为例如white_person 表是这样的，是不是意味着color 和person 属性有特定的关系：

证明表格中的重复属性是否合理？ 证明创建新表并将其视为1-N 关系？但在形式上如何定义这种类型的关系？

【参考方案1】：

现在，如果我们不能将表格更改为例如white_person 表 就是这样，是否意味着属性 color 和 person 有 一种特定的关系，

1) 证明表中的重复属性是正确的？

重复属性在数据库技术中有特定的含义。它确实 not 意味着您可以找到具有相同值的多行。 （这就是 for 的行。）您没有重复属性。

2) 证明创建新表的合理性并将其视为 1-N 关系？但从形式上讲，这种关系将如何 定义？

1-N 关系可以通过函数依赖来识别——你会找到一个人，他的颜色是白色的，他的颜色也是紫红色的。一个人可以在您的数据库中有多少种颜色？

【讨论】：

1) It does not mean you can find multiple rows that have the same value. (That's what rows are for.) 我问的是列的值在所有行中是否相同。并非所有行在所有列中都具有相同的值。 2) A 1-N relationship would be identified by a functional dependency 是的，但是您可以为 1-1 关系创建一个单独的表。这就是我的意思，但也许我不清楚

“我问的是列的值在所有行中都相同。” 这正是我要说的。这就是行的用途。您没有重复属性。

【参考方案2】：

如果在每一行上重复相同的值，因为您实际想要建模的依赖项是 ∅->color，那么您的 Persons 表违反了 2NF：行列式 ∅（空集）是关键。满足 2NF 所需的更改是将颜色属性删除到以 ∅ 为键的新表（即单行表）中。或者完全从模型中删除该属性。

请注意，不会因为表中某些值的巧合而自动暗示依赖关系。问题在于您需要 DBMS 执行哪些业务规则，以及数据模型是否正确支持这些规则。

我讨论了一个类似的例子here。

【讨论】：

什么是∅->color？我不确定你的意思？

X->A 表示函数依赖，其中属性 X 的值确定 A 的值。如果 X 是空集，则意味着必须确定 A 的值而不参考任何其他属性，因此 A 的值对于每一行都是相同的。

【参考方案3】：

如果一个事实可以假设，则不需要存储它。因此，如果有一个个人属性的值是预先知道的，你知道肯定对于数据库中的所有人都是相同的，并且将来始终保持不变，那么你不需要'根本不需要将其物理存储在数据库中。

但我怀疑你能否做出这样的假设。为了降低存储许多重复字符串的成本，请使用细长的surrogate key（例如，一个字节或一个 16 位 int）将颜色分隔到自己的表中，然后从“大”引用它（通过 FOREIGN KEY）桌子。这样，您不是在重复字符串，而是在重复（更细的）整数。这并不是真正的规范化问题（两种变体都是“规范化的”），而是优化物理设计。

但是，如果有 另一个 属性在功能上依赖于颜色，那么您绝对应该拥有单独的表格。否则会出现transitive functional dependencyPK -> 颜色 -> 另一个，违反了 3NF。

例如：

【讨论】：

布兰科：“如果可以假设一个事实，则不需要存储它”。假设应该内置到代码中还是保留在数据库中？我会说这取决于。首先权衡假设发生变化时必须重新发布代码与必须更新数据库中的数据项的潜在成本和风险。

@sqlvogel 我提出了一个相当哲学的观点。我描述的“假设”永远不会改变。当然，现实世界的运作方式不同。

+1：有趣的想法参考另一个表。这是标准做法吗？

@Jin 数据库设计不是千篇一律的命题。你不能只采取“标准做法”（无论它可能是什么）并无条件地应用它。没有设计是完美的——它总是一个权衡。我相信这种特殊的设计对于您的特定情况来说是一个不错的折衷方案，但只有您拥有全面的信息才能做出最终决定。