作爲學習一些數據庫設計技巧的練習，我正在爲虛構的小型電腦商店設計一個數據庫。這個想法是，商店從多個供應商處獲得一些組件，將它們組裝到計算機系統中並將它們出售給客戶。小型電腦商店的數據庫設計，尋求建議
這裏的模型，我拿出這麼遠的圖像： Image
幾點說明：
這種模式的核心實體是項目。它代表了該店所擁有或銷售的單個項目，例如一個精確的i7 920處理器。此商品屬於屬於類別（「處理器」）的產品（本例中爲「Intel i7 920」）。
這些商品通過訂單進入商店。當從供應商訂購組件時，會創建訂單表中的新條目。對於每個訂購的商品，都會創建Items表中的新條目，並在OrderItem中創建相應條目（我無法爲此表提供更好的名稱......）。
OrderItem條目基本上包含商店在供應商發票上收到的內容：商品成本的價格，相同的描述等。如果必須顯示或打印訂單，訂單字段確定商品出現的順序。
另一方面，當客戶購買東西時，創建了發票。他們購買的每件商品都會創建一個InvoiceItem。它基本上和OrderItem一樣。價格區域是客戶將支付的價格（讓我們假設價格不是每個產品的價格，而是針對每個發票定製的，我無法找到具有每種產品價格並能夠跟蹤價格變化的優雅方式） 。如果說明爲空，則相應產品的說明顯示在發票上，否則，可以輸入該發票的自定義說明。
現在棘手的部分是組件表。如果商店銷售稱爲「PC 1」的PC系統，則產品中將存在「PC 1」條目，例如屬於「PC」類別。每次組裝「PC 1」系統時，都會創建一個新項目（productID爲「PC 1」），並且對於該系統的每個組件，會向組件添加條目：assemblyID將是新項目的itemID ，componentID是組件的itemID。
我只是想到了沒有Assemblies表的另一種管理方式：商店可以向0虛構的客戶「賣」零部件（實際上0 CHF），並從虛構的供應商那裏「購買」組裝好的計算機（再次，免費）。這似乎更容易做到，因爲組件會從庫存中消失，但是否有一種將「已售出」組件與「已購買」計算機關聯的簡單方法？
現在，我對我從中學到的東西很滿意。但肯定有一些錯誤或一些更好的方式來表達我無法想到的事情。我很高興收到任何建議和批評。提前致謝！
PS：對不起，如果文本有點長...還有，對於一些糟糕的英語情況感到抱歉（這不是我的主要語言（這也可以解釋一些選擇不好的字段/表名稱（爲此我會更多比較樂意獲得建議）））