你會為樂高使用什麼數據庫和設計
我正在嘗試將我正在設計的一個有趣問題概念化。使用樂高（塑膠建築玩具）作為類比似乎很有效。如果這是一個相當容易辨識的問題，那麼我將不勝感激任何對相關資訊的參考。
鑑於下面的場景詳細資訊，您會選擇哪種數據庫，即 RDB/SQL 或 NoSQL 或 Graph 或 lucene 或？，以及您將如何考慮對設計進行建模。鑑於：
- ***“樂高材料”***或只是可能存在的所有單獨類型的樂高積木。
- 每件作品都有元數據/各種特徵，例如尺寸、顏色、底部/頂部旋鈕和間隙、約束等。
- 您可以使用多個部分創建的所有可能數量的建構塊/模組的***“建構器目錄” 。***
- 這裡的元數據可能包括描述、模組的製造商、用於創建模組的所有元件、預期用途、能夠建構的旋鈕/間隙等。
- “最後的創作”
- 基本上所有作為產品銷售的各種樂高套裝。數據將包括描述建構的通用術語，如“城堡”、“城市”、“飛機”等。然後，詳細說明建構最終創建所需的每個模組的說明。
該解決方案需要解決規模和搜尋我們所有對象及其相互關係的能力。我覺得圖形數據庫可能無法擴展到這個預期目的。此外，數據將隨著上述對象的每次添加而增長。
我們要查詢的問題：
（樂高材料）向我展示我擁有的所有元件……或者……找到一個結構像這樣的元件（使用元數據）以及它在我們的建構器目錄中用於建構模組的所有位置（下） ，以及最終的創作……或者……找到我可以放在這件作品上的所有作品
（建設者目錄）上麵類似的可組合性類型問題，因為它涉及到相互連接的模組，以及最終的創作。另外…找到使用與此類似的樂高積木的其他模組
（最終創作）還有哪些其他創作是該系列的一部分（如蝙蝠俠系列）……或者其他創作使用了類似的模組，或與此創作類似的部分。
一個標準的RDBMS可以很容易地處理這個問題。您有一個定義的模式，一個簡單的模式，它處理常見的行業問題，例如庫存和生產。
在一家工程和製造公司工作後，我們所有的系統（甚至是我們使用的第三方）都在 RDBMS 上，通常是 Microsoft SQL Server。但任何 RDBMS 都可以正常工作，例如 PostgreSQL、Oracle 或 MySQL，僅舉幾個主流選項。所以這是一個真實世界的標準案例。
我要提到的一個提示是，除了我們的原始
Items表（我們在裝配的某個級別銷售或消耗的每個零件號都有一個唯一的行）之外，我們還有一個表，它為所有之間的每個直接父子關係儲存了一行我們的零件編號。這對於查詢我們在銷售的任何最終裝配項目（或進入該最終裝配的子裝配/模組）的任何級別建構的任何和所有可能的*事物組合非常有用。*您可以輕鬆地在遞歸自聯接中使用這樣的表（在大多數 RDBMS 中，這可以通過遞歸 CTE 實現）來獲取零件列表的整個層次結構，然後在您的情況下為 anyModule或FinalCreation. 該表還有一Quantity列，表示特定子部分的多少單位進入父級。這個表的一個例子是，如果你有一個
FinalCreation叫做 ABCD，它由ModuleB 和 C 以及一個名為 D 的原始樂高積木組成。讓我們假設ModuleB 由原始樂高積木 Z 和三個 D 積木組成. 您的 Parent-Child 表的列(ParentItem, ChildItem, Quantity)將有一行用於(ABCD, B, 1)、(ABCD, C, 1)和(ABCD, D, 1)。它也將有一排(B, Z, 1)和(B, D, 3)。使用您的父子表，您可以通過在ParentItem和ChildItem列上相互連接來遞歸地建構這些行的層次結構。您甚至可以通過對Quantity列進行分組和求和來獲得指標，在這種情況下，這會告訴您FinalCreationABCD 需要庫存中總共 4 塊 D 項的原磚。最後，我只想指出，儘管 RDBMS 非常適合您要解決的問題，但大多數類型的數據庫系統都可以處理擴展（就數據量與性能而言）相同（只是為了澄清未來的讀者）。擴展是硬體和架構問題，而不是數據庫系統問題。一些數據庫系統可以以不同的方式支持不同類型的擴展，這可能有利於也可能不利於一個人的需求，但這從來都不是哪個處理性能更好的問題。