Database design 如何为需要快速读取的树状数据结构选择合适的存储技术和设计

我需要设计一个树状数据结构，子实体可以继承或覆盖父实体的值

• 客户
  • 实体
  • • 渠道

若您可以想象上述三个实体，其中客户端位于0级，实体位于1级，通道位于2级。实体级项目可以从客户端级继承或覆盖属性，通道可以从其实体级父级继承或覆盖属性

我还需要将频道细分为多个组，每个频道可以从特定的日期时间开始生效。因此，如果我进行查询以获得一个特定的通道，我将传递当前的时间实例，并且需要返回第一个小于输入datetime参数的项目

希望树的深度设置为3，并且不会有任何扩展。我的问题是，设计这种数据结构的最佳方法是什么

对于每种类型，我应该有3个表，并且有一个设计用于快速访问数据的视图，还是应该有一个表并使用本文中描述的三种树设计方法之一

每种方法的优点和缺点是什么？

注意关系数据库标签

关系模型完美地处理层次结构。没有必要做奇怪的事情，比如在博客帖子中：这是反关系的。层次结构实现简单，所有查询都很简单。使用SQL（RM的数据子语言）获取您需要的数据的任何“图片”或“视图”

• 如果您想要关系型的，肯定有三个表：一个表会很可怕，因为它没有标准化

• 我给您的主键（

  客户端

  ，

  实体

  ，

  频道

  ）是用户用于识别其数据的短名称或代码。在第二和第三个表中，它们是复合材料。这样的钥匙很快
  • 即，它不是代理项，例如

    记录ID、ID、ID

    。代理项始终是一个附加的列和一个附加的索引，这会使表明显变慢。更不用说，所需的代码将是错误和混乱的
• 这对于您的问题级别来说已经足够了，导航结构所需的SQL代码非常简单

• 为了满足属性的“继承或重写”，我可以提供一个更规范化的设计，它将没有空列，但是它需要稍微复杂一些的SQL代码，这可以通过使用视图来简化。请问

关系数据模型

注•符号

• 我所有的数据模型都在中呈现，这是自1993年以来建立关系数据库模型的标准

• 我的是初学者的必备读物

享受吧。

除非你定义，否则在工程中没有“更好”/“最好”这样的东西。同样不幸的是，所有合理的实用定义都需要大量的经验，其中包含大量的因素，这些因素与对细节的敏感度混乱相互作用。做简单的设计。当你通过测量证明一个设计和你能想到的所有备选方案都有问题（无论当时是什么意思），然后问一个非常具体的问题。还应定义“更好”/“最佳”。