让我们以博客引擎的惨败为例。
您有博客，博客中有帖子，帖子中有用于组织目的的标签。在确定标记问题在RDBMS环境中并非无关紧要之后，我们去google寻求指导，并找到以下整洁的解决方案摘要作为第一个关键词：designs和related benchmarks。但是，所有这些都以性能或复杂性为代价。看起来就像一种类似于NoSQL的方法一样，它允许您在列中存储标签列表（在NoSQL中，我们可以将文档存储在文档中）将很好地解决该问题。为什么不使用SQLServer / Qracle / MySQL / Postgres / etc。有吗？
起初我以为可能是因为尺寸不同。但是任何值得注意的RDBMS都允许某种形式的varchar和文本（大小可观）。因此，列的大小（以及不同行中的同一列将具有不同大小的事实不是问题）。因此，让我们将一列相同类型的项目（大多数语言为数组）存储在列表中，而不是存储大量的文本。让我们为高效的精确搜索匹配索引。至少对于所有我需要NoSQL DB的用例来说，它都会消失（我知道很多人都在关注可伸缩性，但是我对此并不了解/不够在意，我没有可伸缩性问题，我遇到了维护噩梦）。由于高效的索引编制，我们对架构进行了简化的设计（与NoSQL文档中的文档一样干净，简单），并具有出色的性能。仍然很陌生，开源数据库（例如Postgres）没有此功能的某种补丁。如今，那些在该领域具有积极性的开发人员似乎迷上了从头开始创建新数据库的方式。
我是否错过了一些惊人的技术障碍，或者上述的RDBMS供应商只是懒惰还是过去？
（a）单元格中应允许使用任何类型的值，包括数组/集合/集合类型（b）在1NF中，仅表示是关系数据。 （但是请注意，从理论上如何定义概念的角度来看，SQL表通常是
NOT
“关系”数据。）日期已就该主题写了数十页。阅读这些内容将为您提供一个答案，比这里提供的答案要完整得多。
确实，就数据库规范化形式而言，数组类型应该是一个很大的问题，但有时您必须过着危险的生活：-）