2017-06-02 143 views
0

我有一個要求,設計一個電子商務應用程序的數據庫,有一個廣泛的產品類別範圍從針到飛機。所有產品都有不同的功能。例如,手機具有特定功能,如內存,相機百萬像素,屏幕尺寸等,而房屋具有地塊大小,樓層和房間數量,車庫大小等。這些特定功能與我們的產品一樣多。惠斯特都有一些共同的特徵,其中大部分都是非常不同和具體的特徵。所以,在設計數據庫時它有點混亂。我是第一次這樣做。有很多產品類別的電子商務網站的數據庫設計

我的查詢是關於數據庫設計的。這是我打算做的:

  1. 創建一個所有領域的主表,告訴如果一個字段是共同的或特定的,並映射他們與各自的產品類別。所有產品將具有「共同」字段,但「特定」僅針對一個類別顯示。

表:ALL_COLUMNS

列: ID, 名, 類型(公共的或特定的), 類別(電話,汽車,膝上型等)

  • 在顯示前面的字段時,從all_columns表中取出各個字段。

  • 存儲與映射字段

    沿另一個表中的用戶數據
  • 表:ALL_USER_DATA

    列: ID, ColumnID的, 值

    我不知道是什麼是正確的方式,以及如何完成已建立的應用程序和網站。所以,如果有人能夠判斷這是否是電子商務應用程序的數據庫架構的正確方式,並且具有高度全面和稀疏的類別和功能,我期待着。

    謝謝大家。

    回答

    0

    這個問題有很多可能的答案 - 請參閱這個問題旁邊的「相關」問題。

    ALL_USER_DATA表的設計通常稱爲「實體/屬性/值」(EAV)。它被廣泛認爲是可怕的(爲什麼要搜索SO) - 它在理論上很靈活,但是想象一下,如果發現「波音製造的飛機至少20米的翼展適合具有新資質的飛行員」 - 您的查詢幾乎變得難以理解。

    另一種方法是創建一個可以存儲多態數據類型的模式 - 再次查看Stack Overflow以瞭解可能的工作方式。

    簡單的答案是,關係模型不適合這種情況 - 您不希望對商店使用的每種新產品類型進行模式更改,也不希望產生數百種不同的表/列。

    我的建議是將核心,通用信息和所有關係存儲在SQL中,並將擴展信息存儲爲XML或JSON。MySQL在查詢JSON方面非常出色,而且它是一種本地數據類型。

    你的數據模型將是這樣的:

    Categories 
    --------- 
    category_id 
    parent_category_id 
    name 
    
    Products 
    -------- 
    product_id 
    price 
    valid_for_sale 
    added_date 
    extended_properties (JSON/XML) 
    
    Category_products 
    ----------------- 
    category_id 
    product_id 
    
    +0

    這不是RM是一個糟糕的配合,它是數據庫管理系統不充分支持相應的DDL。 (通過受限的DDL被用戶界面和優化的表格操作符調用)。只有缺乏支持才使我們「不想」這樣做。從更改模式查詢表與查詢靜態模式中的JSON/XML值的查詢完全相同。 EAV和JSON/XML都將用戶實際關心的表格編碼爲其他數據結構。如果您確實想要以非製表形式查詢或實施該數據(從來就不是EAV的情況),那麼請使用這些數據類型。 – philipxy

    +0

    感謝@ neville-k,正如在引用的鏈接中提到的,我認爲EAV並不完全是一個壞主意,但我喜歡你推薦的方法。您能否介紹一下我們如何以及在桌面和JSON上保存什麼,以便您的方法更加清晰? – chuck

    +0

    如果不知道模式,很難具體說明在關係表中保存什麼。通常情況下,我會將所有產品類型在關係表中的數據以及其他所有內容保存在JSON中... –

    相關問題