使用缩进实现更简单 UI 的“假树”
开发者们在讨论如何用“假树”——即带缩进的平面列表或类似路径的键——来表示 UI 和数据库中的层级数据，而不是显式的父子结构。支持者认为，这些方法更简单、性能更好，并且在只需要嵌套视觉布局时已经足够，符合 YAGNI 原则，可避免不必要的复杂性。反对者则指出，这类编码把展示与数据混在一起，会让未来的子树操作、重排等功能更复杂，并忽视了关系型数据库中成熟的树模型技术，例如邻接表、物化路径、嵌套集合，以及 PostgreSQL 的 `ltree` 这类专用类型。
何时适合使用“假树”
- 多位评论者指出，许多 UI 只需要层级的外观：一个平面列表加上缩进层级通常就够了（例如：由 HTML 标题生成的目录、通过缩进渲染的评论线程）。
- 对这些场景，“假树”被认为更简单、更容易实现，而且更利于缓存。折叠时可以通过遍历同级项，直到找到一个缩进级别相同或更低的项为止。
- 有人认为这符合 YAGNI 思路：如果今天只需要嵌套显示，就不要过度构建完整的树语义。
风险、局限与未来变化
- 许多人警告说，在数据模型中表示视觉层级是“危险且短视”的。
- 用户会把它理解为真正的父子关系；关于子树操作、重排或批量操作的需求往往会在之后出现。
- 批评者强调，仅靠视觉编码来重命名或删除中间节点、强制合法父节点、移动子树，会很别扭或代价高昂。
- 多位评论者表示，文章淡化了这些问题，并夸大了真实树结构的缺点，称其肤浅、像发泄、或标题党。
数据库中的树表示
- 提到了几种经典模型：
- 邻接表（父 ID）。
- 物化路径（例如
a/b/c或点号路径）。 - 嵌套集合 / MPTT，用于高效子树查询。
- PostgreSQL
ltree和 SQL Server 层级类型被提及为原生的、类似物化路径的选项，并附带对标签限制和缺少父节点问题的说明。 - 有人建议先存储顺序/缩进，之后再迁移为父/子结构，因为层级是可以重建的。
性能与工具
- 经验各不相同：递归 CTE 被描述为既“还行而且有趣”，也被描述为在大规模下缓慢或笨重。
- 嵌套 JSON blob 也被提到，作为另一种“假树”，但实际上可能非常忠实于逻辑结构。
- 还有一条元讨论：对这些模式（Celko 风格的层级、经典 SQL 技巧）的了解正在变得越来越少，部分原因是 ORM、NoSQL，以及对数据建模的重视减少。