mysql內容字段的想法:)

我嘗試新的表結構爲我們新的eccomemrce網站，如Wordpress表。但我不確定這是否是一個很好的主意。mysql內容字段的想法:)

我們只有2個產品和其他內容表（例如我們的頁面，附件，甚至訂單）。他們的普通領域保持第一個表（如ID，標題，日期），但他們的專業領域保持第二個表（如價格，數量，選項，功能）。這意味着產品的所有特殊領域都在一個表格中。

我們認爲如果我們巧妙地使用緩存，沒關係。

您認爲如何？

（請，如果你真的有很好的經驗，只是回答這個問題）

表結構：

內容：（表1）

CONTENT_ID TITLE DESCRIPTION DATE

content_fields： （表2）

FIELD_ID CONTENT_ID KEY_NAME VALUE

例（獲取有1個ID產品和航運是免費的）：

SELECT * FROM `contents` as c LEFT JOIN `content_fields` as cf ON c.content_id = cf.content_id WHERE c.content_id = 1 AND cf.key_name = 'free_shipping' AND cf.value = 'yes'

來源

2010-09-20 dino

這聽起來像是通過各種名稱知道的經典反模式，如*「system in system」*，*「database in database」*或*「inner platform effect」*。 – 2011-08-24 11:01:38

我這個模型非常糟糕經驗，才能符合條件？ ;）

這種抽象可能是有道理的，但最重要的一點 - 您必須權衡各種對象之間的相似點和差異點：例如，將CMS模板和電子郵件模板組合在一起是很有意義的（儘可能多部分將被共享），將CMS頁面和交付訂單分組沒有多大意義（因爲它們只有少數相對不重要的共享數據段）。

「什麼是相似的」決定，將是主觀的;但它需要完成。否則，你可能陷入「一切都是物體」的陷阱。

真實故事：我曾與之合作過的一家公司有類似的想法：所有內容（CMS頁面，訂單，客戶，電子郵件）都是實體，存儲在entities表中;特定於對象的屬性轉至entity_properties和entity_property_values表。這是一個巨大的邪惡混亂（TM），因爲對象幾乎沒有任何共同點，所以99％的數據被存儲爲entity_properties和/或對其他實體的各種引用。（換句話說，將所有東西抽象爲一個通用的基礎對象給我們留下了許多無用的基礎對象）。

來源

2010-09-20 12:13:34 Piskvor

這是一個壞主意：不要這樣做！

數據庫表格以及它們之間的關係應該模擬您的數據。

您建議的簡單模型會阻止您有效地索引數據庫，並且使查詢數據非常困難。（您建議的模型有時是必需的，但只有在您不知道數據格式時才適用。）

你是在暗示這個模型，因爲你討厭有很多很多的表？我同意很多表格可能會讓人困惑，但是一個好的命名約定應該將其解決。舉例來說，在我的數據庫之一

所有表有一個字母，然後下劃線的前綴，
所有表做與顧客有前綴c_，例如c_customer和c_address，
所有表與產品相關的產品具有前綴p_，例如p_product和p_price_list。

來源

2010-09-24 10:46:03

mysql內容字段的想法:)

回答

相關問題