你好，我看了幾個類似的帖子，我正在尋找的東西，但沒有一樣是我需要完成的。我正在嘗試使用SQL Server 2008 R2來構建類別結構。在SQL Server 2008 R2中構建類別
我想讓類別讓我們說...服裝，電子，傢俱，工具......等等。
我正在查看一個3字段的表，從一個類別表（類別ID（PK），categoryname，parentID）開始，我發現這是一個標準的做法，可以進行幾層深度而不必重構。
問題在於，讓我們說（電子 - 光盤播放器 - 光盤換片機），（電子 - 照明 - 工作室照明）或（衣服 - 女性 - 裙子），（服裝 - 女性 - 褲子）級別更深？
我該怎麼做品牌？我打算有一個品牌表（brandID（PK），品牌） ，然後Category_Brand表（categoryID，BrandID）將品牌鏈接到類別，當我想使用從數據庫填充的級聯下拉列表時。
對於其餘屬性應用於項目本身的更深層屬性，我應如何處理？但是依賴於類別？顏色，圖案，材質，尺寸？它可以適用於服裝，但不適用於電子產品或工具，男士服裝的尺碼也不同於女士的服裝。 或者我想存儲修整器尺寸和顏色的牀墊，或者我想要存儲牀尺寸（國王，王后，雙牀）的牀以及存儲類型（彈簧，空氣，泡沫，水）的傢俱
我需要什麼是根據項目所屬的類別將項目特定屬性連接到每個項目。在另一個論壇上，我被建議只添加所有misc。屬性到項目表並留下我不使用null的項目。我知道這沒有意義，在我看來，應該有不同的子屬性表與字段相關的字段，他們代表的類別。我想服裝的尺寸例如會有一個查找表，其中每個尺寸都有一個（sizeid）和一個鏈接表，用於多對多關係來連接尺寸和（itemid），儘管這需要一些不同尺寸的表格，因爲男士尺碼和女士尺碼是不同的，或者將所有（類別id）作爲父外鍵的一個表格放在一個表格中，而另一個項目（長度，寬度，高度）的尺寸將存儲在其自身中表與（itemid）一起作爲外鍵？
或者將（sizeid）或（dimensionid）權限存儲到項目表中是一個好主意嗎？
這對我來說似乎對我來說很簡單，但我越看越越多，我越來越困惑於正確的構造方式，我希望它對性能有好處，因爲這可能會變成高容量應用。但不是每個人都希望這樣？
結果我在尋找的是，用戶將使用類別選擇將項目輸入到他們自己的列表中，然後能夠選擇與項目類別相對應的項目的直接屬性。用戶還可以使用類別或項目名稱或用戶在數據庫中搜索項目，並查看項目結果以及屬於該項目的類別和屬性。 – 2014-09-25 04:11:04