2012-04-04 53 views
3

我即將登上我的第一個電子商務數據庫。電子商務項目的數據庫設計(我應該使用EAV方法)

我在大多數電子商務網站上發現的是,這些網站有類別,然後是子類別,然後再次子類別等。並且子類別的深度不固定表示一個類別具有六個嵌套子類別,而其他類別具有不同

現在所有產品都具有與其關聯的屬性。

現在我的問題是,是這些網站不斷添加表嵌套子類別,並保持在數據庫中添加列的屬性

OR

它們適用的東西被稱爲「EAV」模式(如果我是對的)來解決這個問題,或者他們不斷添加列和/或表格,並且不斷更新網頁,就像我在許多網站上發現的那樣,現在有一個新的類別。

(如果他們使用EAV模型,則網站性能影響不是它..)

因爲這是我的第一個電子商務項目,請您提供一些有價值的建議。

感謝,

任何幫助表示讚賞。

+0

閱讀[這篇優秀的文章(「壞CaRMa」)](http://www.simple-talk.com/opinion/opinion-pieces/bad-carma/),並參見[在這5個最高的錯誤列表在數據庫設計中(點#3)](http://www.simple-talk.com/sql/database-administration/five-simple--database-design-errors-you-should-avoid/)爲什麼EAV是一個可怕的壞主意..... – 2012-04-04 12:32:58

回答

6

你需要的是一個組合EAV的對產品功能嵌套集產品類別

儘管我當然同意EAV幾乎總是一個不錯的選擇,但其中EAV是完美選擇的一個應用程序是用於處理在線目錄中的產品屬性。

想想網站如何顯示產品屬性...產品的屬性始終顯示爲一個垂直列表,其中包含兩列:「屬性」|「 「值」。有時候這些列表會顯示多個產品的並行比較。 EAV完美適合做這種事情。對於大多數應用而言,使EAV毫無意義且效率低下的東西正是使EAV對於在線目錄中的產品屬性有意義且高效的原因。

大家總是說「EAV是EVIL!」的原因之一是因爲列名(即屬性的含義)是由表驅動的,因此EAV中的屬性是「無意義的」,因此不被模式定義。模式的全部重點是給你的模型意義,所以這一點很好。 但是在一個在線產品目錄的情況下,產品屬性的含義真的不重要給系統本身。您的產品目錄系統關心產品屬性的唯一原因是將它們轉儲到列表中或可能存儲在產品比較矩陣中。因此在這種特殊情況下,EAV並不是邪惡的

對於產品類別,您需要一個嵌套集模型,如我在this question的答案中所述。嵌套集使您能夠快速檢索,並且能夠遍歷多層次的不平衡層次結構,但會犧牲編輯時的一些預先計算工作量。

相關問題