我有一個網上商店，用戶可以用自己的產品有小商店。這些產品中的每一個都可能有與之相關的問題，並且店主可以回答這些問題。該信息存儲在3個表格中，即「問題」（QuestionID，ProductID，...）表格，「產品」（ProductID，ShopID，...）表格和「商店」（ShopID，OwnerID，...）表。在MySQL中存儲冗餘信息或必要時連接表是更好嗎？
在「問題」表中添加ShopID（允許店主查看他的所有問題）還是加入這三個表以獲得與特定商店匹配的問題是否更好？
加入和避免冗餘信息幾乎總是更好。當您必須這樣做時，您應該只有denormalize才能達到性能目標 - 並且您無法知道是否需要執行此操作，直到您首先嚐試使用normalized表。
請注意，非規範化有助於讀取性能，但會以減慢寫入速度爲代價，並使編碼錯誤更容易導致數據不同步（因爲您現在將多個地方存儲在同一個地方必須確保將其全部更新）。
通常最好避免冗餘信息。這似乎應該是一個相當便宜的連接做適當的索引，我不會以這種方式去規範化，除非我在查詢計劃中看到JOIN引起問題（可能是因爲表中的記錄數）
您還需要考慮讀取與寫入的比率。非規範化將有助於讀取，但會增加寫入開銷。
只有小型數據庫的連接纔會很便宜。如果您正在考慮產品表中的shopID索引的基數，則加入所需的時間可能很長。 – 2010-07-13 12:38:19
@narcisradu - 是的，我之前不得不求助於此，但是我所做的一點是，只有在執行計劃顯示一個案例時才應該這樣做。 – 2010-07-13 12:45:30
你應該有一個許多人的問題和產品之間的多對多關係：
questions_ref（question_id，question_code，問題）
product_questions（pquestion_id，question_id_fk，product_id_fk）
產品（product_id，product_name等）
如果產品可能位於多個商店（即使確定），您也應該在商店和產品之間建立多對多的關係。
shop_products（sproduct_id，product_id_fk，shop_id_fk，sproduct_price，other_shop_specific_param）
商店（shop_id，owner_id_fk，shop_name等）
我覺得你的設計是好的。我不會將ShopID添加到表問題。必要時您應該使用連接。
順便說一句：您應該使用產品和商店之間的m：n關係並刪除商品的ShopID。因此，您可以在不同的商店和中使用相同的產品，這也是產品的相同問題。
問候，拉爾斯
如果店主不同，他絕對應該避免使用產品和商店之間的多對多關係。想象一下，有相同的產品，但價格不同或其他屬性不同。 – 2010-07-13 12:35:43
@narcisradu所以你會有每個商店的產品表？在我的示例shop_products（...，sProduct_price，sProduct_stock） – DRL 2010-07-13 13:05:15
@DRL中，將店鋪特定參數添加到shop_products（）表格非常簡單：雖然技術上確定您店鋪和產品之間的M2M可能不合需要。作爲店主，我希望我的數據與其他店主的數據完全分開，即使兩組數據都在同一個數據庫中。不，每個商店的單獨產品表都是無稽之談，但是，您確實需要商店和產品之間的1對M關係。這可以防止商店之間的數據糾纏，並將大大簡化單個商店的產品數據導入和導出。這很重要，因爲作爲一名店主，我想迅速建立並能夠快速離開。 – 2010-07-13 14:36:01
從設計的角度來看，不需要存儲冗餘數據。在你的情況下，它可能是。嘗試做一些測試，如果查詢時間由於冗餘而得到改進，那麼您應該繼續進行非規範化。
非常感謝大家的幫助。我幾乎相信，存儲冗餘信息會更好，但我今天學到了一些新東西。 有些人指出，在產品和商店之間建立M：M關係會更好，但由於店主完全不同（甚至運輸成本等完全分開），這是沒有意義的（在這種情況下！）。因此，幾家商店不可能共享一個產品（即使它可以說是同一產品）。 – 2010-07-13 22:11:47