電子商務不同的購物車項目數據庫和模型設計

我有一個電子商務網站，有2種類型的產品：書籍&研討會參與。它們是不同的，並且具有不同的屬性。我很好奇，你怎麼會在數據庫和模型模擬這種（因爲你不能繼承多類）電子商務不同的購物車項目數據庫和模型設計

現在，我有這樣的事情： DB

products (id, name ....) 
seminars (id, title, date ....) 
cart (id, session_id ...) 
cart (id, cart_id, type, id_model) the type is product OR seminar

爲模型我有a

cart_item_abstract 
cart_item_product -> cart_item_abstract 
cart_item_seminar -> cart_item_abstract 
cart_order_product -> cart_item_product 
cart_order_seminar -> cart_item_seminar

但是這意味着我必須複製一些命令對象所需的代碼。

來源

2009-09-27 Gabriel Solomon

你可以看看使用多態關聯。基本上存儲相關項目的類型和ID。購物車將有[「產品」，5]或[「研討會」，19]等 – 2012-12-27 11:04:32

看看rails如何處理類級別實現示例的多態連接。 – 2012-12-27 11:05:07

你應該谷歌的繼承映射」，這一切都歸結到這些choices:

SINGLE_TABLE：表每類層次結構，在這種情況下一個類erarchy的類都被映射到一個表。
加入：。表，每個子類，在這一戰略的每個子類都會有它自己的表檢索從超和子類表都加入了對數據庫中的對象這也適用於子類的子類
TABLE_PER_CLASS ：table-per-class，每個具體類都存儲在它自己的表中operties（包括繼承）映射到具體類的表。

的選擇取決於具體的要求 - 性能與簡潔等

來源

2009-09-27 19:29:59 queen3

+1對於如何思考問題的良好的普遍反應 – timdev 2009-09-27 20:54:55

一種方法是簡單地創建一個產品模型，像書籍和研討會的參考資料。因此，書籍和研討會的每個記錄都有一個product_id引用。

就您的購物車代碼而言，您大多隻關心product_id，標題和價格。

您的目錄代碼更關注差異，但是您處理書籍的瀏覽/顯示方式與您在研討會註冊時的不同。但兩者都有產品ID，因此如果用戶「添加到購物車」，則只需告訴購物車「add product id＃123」。對LEFT JOIN和條件的一點思考應該讓購物車很容易找出任何給定產品ID的標題和成本，而不管它的類型如何。

希望這會有所幫助。

來源

2009-09-27 18:42:51 timdev

所以你sugesting有一個單一的表？否則我不知道該ID是否適用於產品或研討會 – 2009-09-27 19:13:00

三個表格：產品，書籍，研討會。產品包含任何共享數據（標題，價格等）。書籍和研討會表格包含特定的內容，並且有一個product_id。 SELECT * FROM產品LEFT JOIN研討會LEFT JOIN書籍WHERE product_id = 123基本上可以滿足您的任何需求。您可能必須在顯示代碼中執行一些條件編碼，但以單向方式處理書籍應該相當容易，而爲了顯示目的而研討另一種方法，而爲了購物車邏輯的目的，將其視爲相同。 – timdev 2009-09-27 20:52:34

-1

在你的數據庫中你不能只有兩個表，一個是產品（id，type，price，title），然後是屬性（id，product_id，attribute，description）？通過這種方式，您可以在產品與屬性之間建立一對多關聯。

在您的購物車模型中，您可能只有一個get-product（）方法，它將返回產品ID，標題和價格。在您的模型中，您可以使用get-product（）方法（或get-product-attribute（$ product-id））方法實際顯示產品目錄中的產品，但會返回產品表中的值並建議將tim join的屬性表作爲tim。

來源

2009-09-27 19:08:00 iangraham

我想了解它..但這會使選擇複雜化很多，例如搜索和過濾，我擔心它會影響性能並使代碼更復雜以保持 – 2009-09-27 19:15:07

EAV被正確地視爲反垃圾郵件，數據庫設計中的模式。 – 2009-09-27 22:50:21

@NoahGoodrich我不是說我同意答案，但你可以瀏覽EAV上的維基http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model - 不是一個提到它是「反模式」。這是一個選擇，就像數據建模中的許多其他人一樣。 – 2012-12-27 10:59:32

你有沒有考慮你的遺傳模式可能存在缺陷？

我認爲一個購物車可能包含一個或多個物品，並且一旦用戶完成購物車中所有物品的購買，就會創建一個訂單。所以一個訂單同樣會包含多個項目。

考慮到這一點，您可以使用繼承映射來創建一個表，該表包含所有項目類型以及類型字段（研討會，產品）之間通用的值。然後，您爲每種類型創建一個表來保存唯一值。

您的基礎商品類應實現一組多態接口，這些接口將返回適當的值，例如商品名稱，商品描述，但需要不同子類中的不同實現。

作爲一個例子，我最近在一個項目中工作，如果用戶是管理員或僱主，我需要返回名稱的用戶名，如果用戶是學生，我需要返回姓氏和名字連接。我創建了一個函數_getName（），它返回適當的值，使用它的代碼（在這種情況下是視圖）不需要執行任何上下文處理。

它應該與您的購物車和訂單類同樣。他們應該能夠與產品和研討班進行互動，而無需執行任何上下文處理。

來源

2009-09-27 23:06:05

電子商務不同的購物車項目數據庫和模型設計

回答

相關問題