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

How to choose the right storage technology and design for a tree like date structure that requires fast reads

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

如果您能想象以上三个实体，其中客户端处于级别 0，实体处于级别 1，渠道处于级别 2。实体级别的项目可以继承或覆盖客户端级别的属性，渠道可以继承或覆盖来自客户端的属性他们的实体级别 parents.

我还需要将频道 sub-sectioned 分组，其中每个频道都可以从特定日期时间开始有效。因此，如果我进行查询以获取特定频道，我将传递当前时间实例，并且我将需要取回小于输入日期时间参数的第一项。

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

我应该为每种类型设置 3 个 table 并拥有一个旨在允许快速访问数据的视图，还是应该设置一个 table 并使用其中一个article?

中描述的三种树设计方法

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

_{注意关系数据库标签}

关系模型 可以很好地处理层次结构。没必要做奇怪的事情，比如博客里的post：就是anti-Relational。层次结构实现简单，所有查询都很简单。使用 SQL，RM 的数据子语言，获取您需要的任何 "picture" 或 "view" 数据。

如果你想要 Relational，肯定是三个 tables：一个 table 会很可怕，因为它没有规范化。
我给你的主键（Client、Entity、Channel）是用户用于识别其数据的简称或代码。在第二个和第三个 table 中，它们是复合体。这样的Key非常快。
- 即。它不是代理项，例如 Record ID, ID, id。代理始终是一个 additional 列和一个 additional 索引，这会使 table 明显变慢。更不用说，所需的代码将是错误和混乱的。
这足以满足您的问题水平，导航结构所需的 SQL 代码很简单。
为了满足 "inheritance or override" 的属性，我可以提供一个更规范化的设计，它不会有 NULL 列，但是它需要稍微复杂一些 SQL代码，可以通过使用 View 来简化。请教

尽情享受吧。