14

您通常对数据库进行规范化以避免数据冗余。在充满名称的表中很容易看出存在大量冗余。如果你的目标是创建一个地球上每个人的名字目录(祝你好运),我可以看到标准化名字是多么有益。但在普通业务数据库的背景下,这是否矫枉过正?

(当然我知道你可以把任何事情做到极致……比如说,如果你归一化为音节……甚至是相邻的字符对。我看不出走那么远有什么好处)

更新:

一个可能的理由是随机名称生成器。这就是我能想到的。

4

19 回答 19

54

是的,这是矫枉过正。

人们不会一下子Bill就改名。Joe

于 2009-04-23T16:39:18.063 回答
35

数据库规范化通常是指规范化字段,而不是其内容。换句话说,您将规范化数据库中只有一个名字字段。这通常是值得的。然而,数据内容不应该被规范化,因为它对那个人来说是个人的——你不是从一个列表中挑选的,你也没有在一个地方改变一个列表来影响每个人——这将是一个错误,而不是一个特性。

于 2009-04-23T16:40:46.827 回答
6

你如何规范一个名字?并非所有名称都具有相同的结构。并非所有国家或文化都使用相同的名称规则。名字不一定只是名字。人们有可变数量的名字。有些国家没有简单的名字/姓氏对。如果我的名字恰好是您的姓氏,在您的数据库中是否应该被视为相同?如果不是,那么您就会遇到一个问题,即姓氏在不同的国家可能意味着不同的东西。在我知道的大多数国家,这是一个姓氏。您的姓氏至少与您父母中的一个姓氏相同。在冰岛,它是你父亲的名字,后面跟着“儿子”或“女儿”。因此,相同的姓氏将意味着完全不同的东西,具体取决于您是否在冰岛和美国遇到它。

在某些文化中,妇女结婚时随丈夫姓是很常见的。在其他文化中,这完全是可选的,甚至可能以相反的方式工作。

你怎么能正常化呢?它会给你带来什么信息?如果你在你的数据库中发现某人的名字最后一个词是“Smith”,这告诉你什么?这可能不是他们的姓氏。它可能只是姓氏的一部分。这在某些语言中可能是一种荣誉,但根据他们的文化,这应该被视为名称的一部分。

只有当数据遵循通用结构时,您才能对其进行规范化。

于 2009-04-23T16:42:50.487 回答
4

如果您需要基于小名称执行查询,我可以看到需要对名称进行规范化。例如,搜索“Betty”可能需要返回“Betty”、“Beth”和“Elizabeth”的结果

于 2015-02-09T20:44:51.477 回答
2

是的,绝对是矫枉过正。朋友之间的几十个字节是多少?

于 2009-04-23T16:38:21.543 回答
2

也许如果你在人口普查办公室工作,这可能是有道理的。否则,请参阅其他答案:)

于 2009-04-23T16:42:40.177 回答
1

我会说是的,在 95% 以上的情况下它走得太远了。

于 2009-04-23T16:38:10.157 回答
1

一般是的。正常化到那个水平会很远。根据查询(例如通常按姓氏搜索的电话簿),这可能是值得的。我希望这种情况很少见。

于 2009-04-23T16:38:33.010 回答
1

是的。我想不出一个好处超过问题和查询复杂性的例子。

于 2009-04-23T16:38:50.777 回答
1

不,但您可能希望将客户规范化为规范记录(因此您的数据库中不会有 5 个不同的“Bloggs & Co.”条目。这是一个经常困扰 MIS 项目的数据清理问题。

于 2009-04-23T16:42:04.857 回答
1

您通常不会在数据库中进行第四种形式规范化。因此,第七形式规范化有点过分了。这甚至可能是一个遥不可及的想法的唯一地方是在某种大型数据仓库中。

于 2009-04-23T16:45:03.133 回答
0

我通常没有看到需要对名称进行规范化,主要是因为这会增加连接的性能,而连接总是会被调用,并且没有任何好处。

如果您有这么多相似的名称,并且存在存储问题,那么这可能是值得的,但需要考虑性能损失。

于 2009-04-23T16:39:42.850 回答
0

我会说这绝对是矫枉过正。在大多数应用程序中,您会经常显示人们的姓名,与之相关的每个查询都会看起来更加复杂和难以阅读。

于 2009-04-23T16:39:59.637 回答
0

是的。人们普遍认为,仅仅应用所有规范化规则可能会导致您走得太远,最终得到一个过度规范化的数据库。例如,可以将每个字符的每个实例标准化为对字符枚举表的引用。很容易看出这很荒谬。

规范化需要在适合您的问题域的级别执行。过度规范化与规范化不足一样是一个问题(当然,出于不同的原因)。

于 2009-04-23T16:40:31.540 回答
0

在某些情况下,能够链接已婚/未婚姓名会很有用。
最近有一个案例,我不得不重命名数千封电子邮件作为交换,因为有人离婚并且不希望任何电子邮件将她列为married_name@company.com

于 2009-04-23T16:43:51.670 回答
0

除非名称构成复合主键并且您拥有依赖于其中一个名称的数据(例如,姓 Plummer 的任何人对数据库一无所知),否则无需规范化到该级别。在这种情况下,如果不进行规范化,您将违反第二范式

于 2009-04-23T16:53:39.057 回答
0

我同意一般的反应,你不会那样做。

不过,我想到了一件事,压缩。如果你有 10 亿人,你发现 60% 的名字是从 5 个非常常见的名字中提取的,你可以使用一些棘手的位操作来显着减小大小。它还需要非常定制的数据库软件。

但这不是为了标准化,只是为了压缩。

于 2009-04-23T17:11:17.470 回答
0

如果您需要避免不破坏它带来的删除异常,您应该将其正常化。也就是说,如果您需要回答这个问题,我的数据库中是否曾经有一个名为“Joejimbobjake”的人,您需要避免异常。软删除可能比拥有一个全面的名字表(例如)要好得多,但你明白我的意思。

于 2009-04-23T17:20:31.630 回答
0

除了其他人提出的所有观点之外,请考虑如果您正在实施数据输入操作(例如),并且要插入新联系人,您将必须搜索您的名字和姓氏表以找到正确的Id,然后使用这些值。但是,当姓名不在 FN 和/或 LN 表上时,情况会变得更加复杂,那么您必须插入新的名字/姓氏并使用新的 ID。

如果你认为你有一个完整的名字列表,再想一想。我使用了超过 20 万个唯一名字的列表,我猜它代表了 99.9% 的美国人口。但那 0.1% = 很多人。不要忘记外国名字和拼写错误......

于 2009-04-23T19:54:13.257 回答