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數組，則希望將其作為一個單獨的結構進行操作，僅用於搜索，而不能一次更新多個節點。

在大多數情況下，更詳細的樹輪廓將很有意義並且更易於使用。