JSON树存储格式答案

【问题标题】：JSON tree storage formatJSON树存储格式
【发布时间】：2018-09-04 16:42:19
【问题描述】：

这更像是一个概念类型的问题，用于存储和更新树的数据。让我们举一个常见的例子——来自 React 之类的虚拟 dom。

代表 dom 的树的通用 json 存储类似于：

{
  nodeId: 'nodeId1',
  ...nodeData,
  childrenNodes: [
    {
      nodeId: 'nodeId2',
      ...nodeData,
      childrenNodes: [...]
    },
    ...
  ]
}

所以，我正在查看具有 BFS 或 DFS 的树（我相信 React 会进行 DFS）以找到一个特定元素来更改它。

同一棵树的另一种可能实现可能是我将它存储在更像哈希表的格式：

{
  nodeId1: {...nodeData, childrenNodes: [nodeId2]},
  nodeId2: {...nodeData, childrenNodes: [nodeId3, nodeId4]},
  ...
}

因此获取特定节点可能是 O(1)，因为我们只是对所有节点 ID 进行哈希处理，而不是每次都必须遍历树。

对于像虚拟 dom 这样的东西，我们可以存储数万甚至数十万个可能元素的状态，我认为存储一种方式而不是另一种方式可以忽略不计，但我们可能不希望同时拥有两种结构在内存中（尽管两者都可以？）。

假设两个结构都为每个节点分配了 id，那么在这两种情况下添加和删除节点都相当容易。我们还可以假设在这两种情况下，每个子节点都有对其父节点的引用。

我要解决的问题是，在一般情况下使用哪种结构更有意义，或者如果我们专注于尽快更新一个节点或一组节点，那么跟踪这两种结构是否有意义?如果我要从头开始制作一个框架，我可以看到这两种情况对不同的场景都很有用，但我必须记住有限的内存设备，比如旧手机。

【问题讨论】：

标签： javascript json data-structures

【解决方案1】：

没有人回答，所以我只是根据额外的研究和观察给出我的意见。

在某些访问节点的场景中，所提出的哈希解决方案会更快。然而，可读性和将此解决方案扩展到其他可能的集成使其成为一个更难处理的结构。如果我要使用这些 id 数组，我希望将其作为一个单独的结构，仅用于搜索，而不是一次更新多个节点。

对于大多数情况，更详细的树形轮廓会更有意义并且更易于使用。

【讨论】：