更新：關係（或 NoSQL）數據庫設計
（用更多細節更新了這個問題。決定使用關係數據庫，並希望對其設計發表一些評論）
該數據庫保存用於造船的裝配指令數據，稍後在增強現實 Android 應用程序中使用。應用程序向伺服器 (Node.JS) 請求必要的文件。
簡單地說：工作包包含幾個必須安裝的元件，這些元件中的每一個都有應用程序所需的文件。
- 工作包依賴於其他工作包（WD_Dependencies），上圖中，S1依賴1和2；
- 工人可以被分配一個特定的工作包，如果沒有，返回的工作包是類型和部門之間的匹配組合。
更新：
（在新標籤中打開以獲得更好的視圖）
數據庫在項目藍圖和該藍圖的具體執行之間“劃分”。這也允許多次執行同一個藍圖。
問題：
- 這是一個好的設計嗎？劃分藍圖和項目？
- 遞歸查找工作包的所有依賴項的高效 SQL 查詢？
- 您是否發現關係有任何問題或任何冗餘？
- 歡迎任何意見或幫助。
我知道這可能是一個廣泛/意見的問題，但我對這種規模的數據庫沒有經驗，希望能得到幫助。
這兩個選項中哪一個是最好的？
關係設計明顯優於 NoSQL 範例中使用的分層設計。使用關係原則設計的數據庫模式不支持一種訪問路徑而不是另一種訪問路徑。每個表都代表一個真實世界的實體類型，並且通過使用任意複雜性的關係代數查詢，可以建構來不僅回答目前的數據問題，而且回答您認為尚未想到的任何未來問題。分層架構將單一結構強加於數據 - 在這種情況下，工作包包含其他工作包、工作程序、元件和文件。如果您想詢問與此單一視圖不一致的數據的問題，即使不是不可能，也會更加困難。此外，
工作包應該參考上述工作包，還是相反更好？
實現這一點的最佳方式是創建一個新表來表示父工作包和依賴工作包之間的連結，同時讓工作包表代表工作包本身，而不考慮依賴關係。此設計不會將依賴於其他工作包的工作包與不依賴於其他工作包的工作包混合在一起**。**依賴他人。關係方法的一個關鍵優勢是具有一組運算符的單個結構（關係表和關係代數）可以輕鬆表示層次結構或網路。網路 DBMS 需要兩種類型 - 節點和連結 - 具有兩組不同的運算符，因此復雜性增加了一倍。分層 DBMS 根本無法正確表示網路。這是當今可用的 NoSQL 系統只能解決一小部分案例的關鍵原因。 Fabian Pascal的書Practical Issues in Database Management第 7 章對使用 SQL 的數據層次結構進行了出色的概述，我強烈推薦它。
將會有大量的讀取，但是寫入會相當少。
關係方法的另一個好處是系統的性能可以在很大程度上在物理級別進行管理，而不會影響應用程序用於處理數據的邏輯數據庫模式。使用關係方法，您可以首先關注正確的邏輯模式，然後在大多數情況下讓 DBA 實施正確的物理設計和基礎架構，以最好地支持讀取繁重的工作負載。在導航系統中，程序員必須直接在程序中指定訪問路徑，情況並非如此。