注：
这个话题正在讨论中，其他话题中也引用了这个话题，所以我已经给了它一个合理的处理，请多多包涵。我的目的是提供理解，以便您可以做出明智的决定，而不是仅仅基于标签的简单化决定。如果您觉得它很激烈，请在闲暇时分块阅读；饿了就回来，而不是之前。
确切地说，关于 EAV，什么是“坏的”？
1 简介
EAV 做得好和做得不好是有区别的，就像 3NF 做得好和做得不好一样。在我们的技术工作中，我们需要准确了解哪些有效，哪些无效；关于哪些表现良好，哪些表现不佳。笼统的陈述是危险的，会误导人们，从而阻碍对相关问题的进展和普遍理解。
我不赞成也不反对任何事情，除了不熟练的工人执行不力以及歪曲标准的遵守程度。在我看到误解的地方，就像这里一样，我将尝试解决它。
规范化也经常被误解，所以说一下。维基百科和其他免费资源实际上发布了完全荒谬的“定义”，没有学术基础，有供应商偏见，以验证他们不符合标准的产品。有一个 Codd 发表了他的十二条规则。我至少实现了 5NF，这对于大多数需求来说已经绰绰有余，所以我将使用它作为基线。简而言之，假设读者理解第三范式（至少该定义不会混淆）......
2 第五范式
2.1 定义
第五范式定义为：
- 每列与主键有 1::1 的关系，只有
- 并且没有其他列，在表中，或在任何其他表中
- 结果在任何地方都没有重复的列；无更新异常（无需触发器或复杂代码来确保在更新列时，正确更新其重复项）。
- 它提高了性能，因为 (a) 它影响较少的行，并且 (b) 由于减少了锁定而提高了并发性
我的区别是，数据库是否被规范化为特定的 NF；数据库只是标准化的。就是每个表都被规范化为一个特定的 NF：一些表可能只需要 1NF，另一些需要 3NF，还有一些需要 5NF。
2.2 性能
曾经有一段时间，人们认为 Normalization 不能提供性能，不得不“为性能而去规范化”。感谢上帝，神话已被揭穿，今天大多数 IT 专业人员都意识到规范化数据库的性能更好。数据库供应商针对规范化数据库进行优化，而不是针对非规范化文件系统进行优化。“非规范化”的事实是，数据库一开始就没有规范化（而且表现很差），它是非规范化的，他们做了一些进一步的努力来提高性能。为了被非规范化，它必须首先被忠实地规范化，而这从未发生过。我已经重写了许多这样的“为性能而去规范化”的数据库，只提供忠实的规范化而不是其他任何东西，它们至少运行了十倍，甚至快了一百倍。此外，它们只需要一小部分磁盘空间。它是如此的行人，我以书面形式保证锻炼。
2.3 限制
限制，或者更确切地说 5NF 的全部范围是：
- 它不处理可选值，并且必须使用 Nulls（许多设计人员不允许 Nulls 并使用替代品，但如果没有正确和一致地实施，这会受到限制）
- 您仍然需要更改 DDL 才能添加或更改列（并且在实施之后，添加最初未确定的列的要求越来越多；更改控制繁重）
- 尽管由于规范化（阅读：消除重复和混淆关系）提供了最高水平的性能，但复杂的查询，如旋转（生成行的报告，或行的摘要，表示为列）和“列访问”数据仓库操作很困难，而且只有这些操作执行得不好。这并不是说这仅仅是由于可用的 SQL 技能水平，而不是由于引擎。
3 第六范式
3.1 定义
第六范式定义为：
它被称为不可约范式，最终的 NF，因为没有进一步的归一化可以执行。虽然在九十年代中期学术界有讨论，但直到 2003 年才正式宣布。对于那些喜欢通过混淆关系、relvars、“关系”之类来诋毁关系模型形式的人来说：所有的废话都可以被搁置，因为正式地，上述定义标识了不可约关系，有时称为原子关系。
3.2 进展
6NF 提供的增量（5NF 没有）是：
- 对可选值的正式支持，从而消除空问题
- 副作用是，无需更改 DDL 即可添加列（稍后会详细介绍）
- 轻松转动
- 简单直接的列访问
让我说我（和其他人）在 20 年前就提供了增强的 5NF 表，明确用于透视，完全没有问题，因此允许（a）使用简单的 SQL 并且（b）提供非常高的性能；很高兴知道该行业的学术巨头已经正式定义了我们在做什么。一夜之间，我的 5NF 表被重命名为 6NF，而我连一根手指都没有。其次，我们只在需要的地方这样做；同样，归一化为 6NF 的是表，而不是数据库。
3.3 SQL 限制
它是一种繁琐的语言，尤其是 re joins，做任何适度复杂的事情都会使其非常繁琐。（这是一个单独的问题，大多数编码人员不理解或不使用子查询。）它支持 5NF 所需的结构，但仅支持。对于健壮和稳定的实现，必须实现额外的标准，这些标准可能部分由额外的目录表组成。到 90 年代初，SQL 的“使用期限”已经过去了。它完全不支持 6NF 表，迫切需要更换。但这就是我们所拥有的，所以我们只需要处理它。
对于我们这些一直在实施标准和附加目录表的人来说，扩展我们的目录以提供支持 6NF 结构到标准所需的能力并不是一项认真的努力：哪些列属于哪些表，以什么顺序；强制/可选；显示格式；等等。本质上是一个完整的元数据目录，与 SQL 目录结合。
请注意，每个 NF 都包含其中的每个先前的 NF，因此 6NF 包含 5NF。我们没有打破 5NF 以提供 6NF，我们提供了 5NF 的进展；在 SQL 不足的地方，我们提供了目录。这意味着基本约束，例如外键；通过 SQL 声明性引用完整性提供的值域；数据类型；检查；和 RULES 在 5NF 级别保持不变，并且这些约束没有被颠覆。引入 6NF 并没有降低符合标准的 5NF 数据库的高质量和高性能。
3.4 目录
保护用户（任何报告工具）和开发人员免于处理从 5NF 到 6NF 的跳跃是很重要的（他们的工作是成为应用程序编码极客，我的工作是成为数据库极客）。即使在 5NF 中，这始终是我的设计目标：一个适当规范化的数据库，具有最小的数据目录，实际上非常易于使用，我无法放弃它。请记住，由于正常的维护和扩展，6NF 结构会随着时间而变化，数据库的新版本会定期发布。毫无疑问，从 6NF 表构建 5NF 行所需的 SQL（在 5NF 时已经很麻烦）更加麻烦。谢天谢地，这完全没有必要。
由于我们已经有了我们的目录，它标识了完整的 6NF-DDL-that-SQL-does-not-provide，如果您愿意，我编写了一个小实用程序来读取目录，并且：
- 生成 6NF 表 DDL。
- 生成 6NF 表的 5NF 视图。这使用户可以完全不知道它们，并为他们提供与 5NF 相同的功能和性能
- 生成针对 6NF 结构进行操作所需的完整 SQL（不是模板，我们单独提供），然后编码人员使用这些 SQL。他们从原本需要的乏味和重复中解脱出来，并且可以自由地专注于应用程序逻辑。
我没有为 Pivoting 编写实用程序，因为消除了 5NF 中存在的复杂性，并且它们现在编写起来非常简单，就像 5NF-enhanced-for-pivoting 一样。此外，大多数报告工具都提供了数据透视，所以我只需要提供包含大量统计数据的功能，这些功能需要在发送到客户端之前在服务器上执行。
3.5 性能
每个人都有自己的十字架要背；我碰巧痴迷于性能。我的 5NF 数据库表现良好，所以让我向您保证，在将任何东西投入生产之前，我运行的基准测试远远超过了必要的数量。6NF 数据库的性能与 5NF 数据库完全相同，没有更好，也没有更差。这并不奇怪，因为“复杂”的 6NF SQL 唯一能做的，而 5NF SQL 没有的，就是执行更多的连接和子查询。
你必须检查神话。
- 任何对问题进行基准测试（即检查查询的执行计划）的人都会知道Joins Cost Nothing，这是一个编译时解决方案，它们在执行时没有影响。
- 是的，当然，加入的表的数量；被连接的表的大小；是否可以使用索引；正在加入的密钥的分布；等等，都需要一些东西。
- 但是加入本身不需要任何费用。
- 如果对非规范化数据库中的五个（较大）表进行查询，则比对同一数据库中十个（较小）表的等效查询要慢得多。关键是，四个和九个连接都不花钱；他们没有考虑到性能问题；每个 Join 上的选定集确实在其中出现。
3.6 好处
不受限制的柱状访问。这就是 6NF 真正脱颖而出的地方。直接的列访问非常快，以至于无需将数据导出到数据仓库即可从专门的 DW 结构中获得速度。
我对一些 DW 的研究（并不完整）表明，它们始终按列存储数据，而不是按行存储数据，这正是 6NF 所做的。我是保守的，所以我不打算宣布 6NF 将取代 DW，但就我而言，它消除了对 DW 的需求。
比较 6NF 中可用的功能与 5NF 中不可用的功能（例如 Pivoting）是不公平的，后者显然运行得更快。
那是我们第一个真正的 6NF 数据库（具有完整的目录等；与始终只在必要时进行增强的 5NF 不同；后来证明是 6NF），客户非常高兴。当然，在交付后我会监控一段时间的性能，并且我为我的下一个 6NF 项目确定了一种更快的列访问方法。当我这样做时，可能会对 DW 市场产生一些竞争。客户还没有准备好，我们不会修复没有损坏的东西。
3.7 确切地说，关于 6NF，什么是“坏的”？
请注意，并非每个人都会以尽可能多的形式、结构和遵守标准来完成这项工作。因此，从我们的项目中得出所有 6NF 数据库性能良好且易于维护的结论是愚蠢的。（通过查看其他人的实现）得出所有 6NF 数据库性能不佳、难以维护的结论同样愚蠢。灾难。与往常一样，任何技术上的努力，除了相关的技能组合外，所产生的性能和易于维护都严格依赖于形式、结构和对标准的遵守。
3.8 可用性
请不要暴露自己，索取任何超出标准商业惯例界限的东西，例如“已发表的参考资料”，客户是澳大利亚银行，整个实施过程是保密的；但我可以自由地接受潜在客户的访问。也欢迎您在我们位于悉尼的办公室查看（但不能复制）文件。方法（公开可用的 6NF 教育之外的结构和标准）和实用程序是我们的专有知识产权，可用于作业。在这个阶段，我只是将它作为任务的一部分出售，因为（a）我需要合理地确保项目的成功（为了不损害我们的声誉），并且（b）我们拥有一个成功的项目是不够的成熟度将其归类为“准备上市”。
我很高兴继续回答问题，并提供有关 6NF 目录的有用信息，建议哪些有效，哪些无效等，而无需实际发布我们的 IP（文档）。我也很高兴为您运行合格的基准测试。
4 实体属性值
披露：经验。我检查了其中一些，主要是医院和医疗系统。我已经对其中两个进行了纠正作业。海外供应商最初的交付是相当充足的，虽然不是很好，但本地供应商实施的扩展是一团糟。但几乎没有人们在这个网站上发布的关于 re EAV 的灾难。几个月的紧张工作很好地修复了它们。
4.1 它是什么
对我来说很明显，我从事的 EAV 实现只是第六范式的子集。实施 EAV 的人这样做是因为他们想要6NF 的一些特性（例如，能够在不更改 DDL 的情况下添加列），但他们没有实施真正 6NF 的学术知识，或者实施和管理它的标准和结构安全地。甚至最初的供应商也不知道 6NF，或者 EAV 是 6NF 的一个子集，但当我向他们指出时，他们欣然同意。因为提供 EAV 所需的结构，实际上是 6NF，有效和有效（目录；视图；自动代码生成）在 EAV 社区中没有正式确定，并且在大多数实现中都缺少，我将 EAV 归类为混蛋儿子第六范式。
4.2 关于 EAV，究竟什么是“坏的”？
根据这个和其他线程中的评论，是的，EAV 做得不好是一场灾难。更重要的是（a）它们太糟糕了，以至于 5NF（忘记 6NF）提供的性能丢失了，并且（b）没有实现与复杂性的普通隔离（编码人员和用户“被迫”使用繁琐的导航）。如果他们不实施目录，就无法防止各种可预防的错误。
对于糟糕的（EAV 或其他）实现来说，所有这些都可能是正确的，但这与 6NF 或 EAV 无关。我工作的两个项目都有相当好的性能（当然，它可以改进；但没有因为 EAV 导致性能不佳），并且很好地隔离了复杂性。当然，它们远不及我的 5NF 数据库或我真正的 6NF 数据库的质量或性能，但考虑到对 EAV 社区中发布的问题的理解程度，它们足够公平。它们不是这些页面中所谓的 EAV 的灾难和不合标准的废话。
5 空
有一个众所周知且记录在案的问题，称为空问题。它本身就值得写一篇文章。对于这篇文章，我只想说：
- 问题实际上是可选值或缺失值；这里考虑的是表设计，因此没有 Nulls 与 Nullable 列
- 实际上没关系，因为无论您是否使用 Nulls/No Nulls/6NF 来排除缺失值，您都必须为此编写代码，而问题正是处理缺失值，这是无法规避的
- 当然除了纯 6NF，它消除了 Null 问题
- 处理缺失值的编码仍然存在
- Null 对性能来说是个坏消息，我们中的许多人几十年前就决定不允许在数据库中使用 Null（在传递的参数和结果集中使用 Null 来表示缺失值，这很好）
- 这意味着一组 Null Substitutes 和布尔列来指示缺失值
- Null 导致原本固定的 len 列变为可变 len；永远不要在索引中使用可变 len 列，因为在遍历或潜水期间，必须对每个索引条目的每次访问都执行一点“解包”。
6位
我不是 EAV 或 6NF 的支持者，我是质量和标准的支持者。我的立场是：
始终，在所有方面，按照你所知道的最高标准做你正在做的事情。
对于关系数据库（对我来说是 5NF），规范化到第三范式是最小的。数据类型、声明性引用完整性、事务、规范化都是数据库的基本要求；如果它们丢失，则它不是数据库。
- 如果你必须“为了性能而去规范化”，你就犯了严重的规范化错误，你的设计没有规范化。时期。不要“反规范化”，相反，学习 Normalization 和 Normalise。
没有必要做额外的工作。如果 5NF 可以满足您的要求，请不要实施更多。如果您需要可选值或无需更改 DDL 即可添加列或完全消除 Null 问题的能力，请仅在需要它们的表中实施 6NF 。
如果你这样做，仅仅是因为 SQL 没有为 6NF 提供适当的支持，你将需要实现：
- 一个简单而有效的目录（列混淆和数据完整性丢失是不可接受的）
- 通过 VIEWS 对 6NF 表进行 5NF 访问，以将用户（和开发人员）与受阻（非“复杂”）SQL 隔离
- 编写或购买实用程序，以便您可以生成繁琐的 SQL 来从 6NF 表构造 5NF 行，并避免编写相同的
- 测量、监控、诊断和改进。如果您遇到性能问题，则您已经犯了 (a) 规范化错误或 (b) 编码错误。时期。备份几个步骤并修复它。
如果您决定使用 EAV，请认清它是什么，6NF，并正确实施它，如上所述。如果你这样做，你将有一个成功的项目，保证。如果你不这样做，你会得到狗的早餐，保证。
6.1没有免费的午餐
这句格言被提及，但实际上被滥用了。它实际深入应用的方式如上所述：如果您想要 6NF/EAV 的好处，您最好也愿意做获得它所需的工作（目录、标准）。当然，推论是，如果你不做这项工作，你就不会得到好处。没有数据类型的“丢失”；价值领域；外键；检查；规则。在性能方面，6NF/EAV 没有性能损失，但对于不达标的工作总是有相当大的性能损失。
7 具体问题
最后。考虑到上述情况，而且这是一个小团队的小项目，毫无疑问：
不要使用 EAV（或 6NF）
不要使用 Nulls 或 Nullable 列（除非您希望破坏性能）
对常见的付款列使用单个付款表
以及每个 PaymentType 的子表，每个子表都有其特定的列
所有完全类型转换和约束。
这是什么“另一个row_id”业务？为什么你们中的一些人在所有移动的东西上都贴上身份证，而不检查它是鹿还是鹰？不 ，孩子是受抚养的孩子。关系是 1::1。child 的 PK 就是 parent 的 PK，常见的 Payment table。这是一个普通的 Supertype-Subtype 集群，Differentialator 是 PaymentTypeCode。子类型和超类型是关系模型的普通部分，在数据库以及任何好的建模工具中都得到了充分的满足。
当然，对关系数据库一无所知的人认为他们在 30 年后发明了它，并给它起了有趣的新名字。或者更糟糕的是，他们故意重新标记它并声称它是他们自己的。直到一些受过教育和职业自豪感的可怜草皮揭露无知或欺诈行为。我不知道它是哪一个，但它就是其中之一；我只是陈述事实，这些事实很容易证实。
A. 对评论的回应
A.1 归属
我说“我忠实于 RM”，并提到“行业巨头”，我认为 IT 专业人员会理解这意味着什么。谦虚的道歉。
- 我没有个人或私人或特殊定义。有关以下定义（例如命令）的所有陈述：
- 正常化，
- 范式，和
- 关系模型。
.
请参阅 EF Codd 和 CJ Date 的许多原始文本（网络上没有免费提供）
。
最新的是CJ Date、Hugh Darwen、Nikos A Lorentzos的时间数据和关系模型
。
除了那些文本之外别无他物
。
“我站在巨人的肩膀上”
。
- 上述内容的本质、主体、所有关于执行的陈述（例如主观和第一人称）均基于经验；作为商业组织（受薪顾问或经营顾问），在美国和澳大利亚的大型金融机构实施上述原则和概念，超过 32 年。
- 这包括纠正或替换不合标准或非关系实现的大量大型作业。
.
- The Null Problem vis-a-vis Sixth Normal Form
与标题相关的免费白皮书（它并没有单独定义The Null Problem）可在以下网址找到：
http ://www.dcs.warwick.ac.uk/~休/TTM/Missing-info-without-nulls.pdf。
.
可以在 p6 上找到 6NF 的“简而言之”定义（对那些经历过其他 NF 的人有意义）
A.2 支持证据
正如一开始所说，这篇文章的目的是为了反击这个社区中普遍存在的错误信息，作为对社区的服务。
如果确定了具体的陈述，则可以提供支持上述原则实施的陈述的证据；并且在同样程度上，其他人发布的不正确的陈述，这篇文章是对它的回应，同样得到了证明。如果要打馒头，让我们确保比赛场地是公平的
这里有一些我可以立即上手的文档。
一个。大型银行
这是最好的例子，因为在这篇文章中明确说明了原因，并且目标已经实现。他们有一个 Sybase IQ（DW 产品）的预算，但是当我们完成项目时报告的速度非常快，他们不需要它。交易分析统计数据是我的5NF 加上旋转扩展，结果是 6NF，如上所述。我认为评论中提出的所有问题都已在文档中得到解答，除了：
- 行数：
- 旧数据库未知，但可以从其他统计数据推断
- 新数据库 = 20 个表超过 100M，4 个表超过10B。
湾。Small Financial Institute A
部分 B 部分- 肉类
C 部分- 参考图表
D 部分- 附录，之前/之后的指数审计（每个指数 1 行）
注意四个文档；第四种仅适用于希望查看详细索引更改的人。他们正在运行一个无法更改的第 3 方应用程序，因为本地供应商已经停业，再加上 120% 的扩展，他们可以但不想更改。我们被邀请是因为他们升级到了新版本的 Sybase，它速度更快，改变了各种性能阈值，从而导致大量死锁。在这里，我们完全标准化了服务器中的所有内容，除了db 模型的目标是（事先保证）消除死锁（抱歉，我不打算在这里解释：争论“非规范化”问题的人会对此表示赞同）。它包括对“将表拆分为存档数据库以提高性能”的逆转，这是另一篇文章的主题（是的，新的单个表比两个溢出的表执行得更快）。此练习也适用于 MS SQL Server [插入重写版本]。
C。耶鲁纽黑文医院
那是耶鲁医学院，他们的教学医院。多年来一直支持他们。基于 Sybase 的第三方应用程序。统计数据的问题是，80% 的时间他们只在指定的测试时间收集快照，但没有一致的历史记录，因此没有“之前的图像”来比较我们新的一致统计数据。我不知道有任何其他公司能够以自动方式在同一图表上获取 Unix 和 Sybase 内部统计信息。现在网络是门槛（相信读者会理解这是一件好事）。
只是一些开始，已经被清除出版。好的，让我们有一些证据支持“'非规范化'提高性能”等概念。轮到你了。