这与这个问题有关。它让我想到，例如，这本书。与其在树和中分别成为[Agriculture]和的子级，不如将这些级别作为标签独立存在。[Other][Books > Catalogs > Agriculture][Business & Industrial > Agriculture & Forestry > Other]
在像 eBay 这样的网站中，如果数据被正确规范化，列出所有带有标签 [AgricultureAND的记录的性能成本是否会Catalog]大大超过列出该[Books > Catalogs > Agriculture] 类别中的所有记录的性能成本？
我意识到这可能是一个愚蠢的问题（不，我不认为我正在为下一个 eBay 编程），但我无法摆脱这种好奇心，更糟的是；诱惑；_ 所以我宁愿现在听起来很愚蠢，并很好地理解我的误解，而不是以后做一些愚蠢或毫无意义的事情。
当关系模型第一次出现时，占主导地位的数据库范式是分层的。然后（仍然如此）分层更有效，因为从本质上讲，您可以从部分预连接查询开始。
但仅基于一种静态层次结构。当您想将数据视图从另一个根维度弯曲时，就会出现很大的困难。（关系数据库在实际使用中是否足够高效，这是一个激烈争论的问题；很快通过摩尔定律的勤奋应用得到解决。）
想想拥有包含产品的订单的客户；一个层次结构。不可避免地，您还希望能够考虑将在客户订单中找到的产品；整个其他层次结构。以及从客户那里生成订单的区域销售人员；或让客户下订单。
关系数据库使您能够以大致相同的效率随意重构层次结构；以嵌入多个正交层次结构为代价的仅在其他数据库格式中可用的好处；在这种情况下，更改、添加或删除数据的成本将是天文数字。
关系模型的主要目的是防止重复。分层数据虽然更容易手动挖掘，但存在重复问题。
使用最适合您的数据的模型，而不是过早地进行优化。
我倾向于从关系数据中构建表现层次树。