圖形數據庫建模

Question

來自SQL/NoSQL背景我發現對圖形數據庫中最簡單的練習進行建模（有效率）是相當具有挑戰性的。儘管不同的技術有其侷限性和最佳實踐，但我不確定我在創建模型時使用的思維方式是否正確，因此，我需要指導，建議和/或資源來幫助我更接近正確的做法。

---

我試過的初始練習是在圖形數據庫中表示一個文件共享整個目錄（子文件夾和文件）。例如，我想包括的一些屬性和查詢是;

• 文件夾的層次結構
• 在當前節點
• 如果能夠根據誰創建的文件/文件夾
• 如果能夠在文件類型搜索來搜索的總大小

這使我對以下問題

1. 何時/哪些屬性應該用於邊緣。只有我打算搜索的那些？只有關係？

2. 我是否應該擴展我的圖形功能，例如，搜索大於X的文件？如何最大限度地發揮模型的未來能力/靈活性，從而使這些變化不會造成巨大影響。

---

目前我正在探索InfiniteGraph和TitanDB。

Answer 1

1）我能想到的描述文件夾層次結構邊緣的唯一屬性是它是包含還是包含關係。如果你決定考慮你所有的邊緣，你甚至不需要這樣做，就你而言，看起來你幾乎總是在詢問後代搜索並返回聚合大小。

這比網絡或邊緣可能具有不同類型的層次結構要簡單得多。想想一個組織結構圖，不僅要跟蹤誰管理誰，還要支持誰，導師，誰騷擾誰，等等。

2）我不熟悉你提到的兩個數據庫，但Neo4J允許在節點屬性上使用索引，因此在file_size上添加索引應該沒有太大的影響。它也是「無模式」，因此您可以即時添加屬性，並且各個節點可能包含不同的屬性。