JSON树存储格式

Question

这更多是概念性的问题类型，用于存储和更新树的数据。 让我们举一个常见的例子-来自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，则在两种情况下添加和删除节点都非常容易。 在这两种情况下，我们都可以假定每个子节点都有对其父节点的引用。

我要问的问题是，在一般情况下使用哪种结构更有意义，或者如果我们专注于尽快更新一个节点或一组节点，那么对这两个结构进行跟踪是否有意义？ 如果我要从头开始构建框架，我会发现这两种情况在不同情况下都是有用的，但我必须牢记有限的存储设备（例如旧手机）。

Answer 1

没有人回答，因此我将基于其他研究和观察给出我的意见。

在某些访问节点的方案中，提出的哈希解决方案会更快。 但是，可读性强并且将此解决方案扩展到其他可能的集成，使它的处理起来要困难得多。 如果要使用这些ID数组，则希望将其作为一个单独的结构进行操作，仅用于搜索，而不能一次更新多个节点。

在大多数情况下，更详细的树轮廓将很有意义并且更易于使用。