數據庫結構 - 是mySQL的正確選擇嗎？

Question

我們目前正在規劃一個非常複雜的電子商務Web應用程序的數據庫結構，它具有靈活性作爲其主要基石。

我們的應用程序具有大量數據（產品），我們遇到輕微頭疼的情況，試圖在不影響數據庫規範化規則的情況下保持高性能，或者在集成產品選項時留下高度可愛的靈活性概念廣泛稱爲產品屬性或參數）。

根據各種參考資料和可用資源，我們列出了所有主要和衆所周知的數據庫模式的優缺點，以解決此問題。比較這些之後，我們已經提出了兩個最終選擇：

• EAV（實體 - 屬性 - 值模型）：

  優點：信息數據庫用於所有的排序。

  缺點：所有相關的查詢都會包含多個表之間的連接以完成數據收集。

• SLOB（序列化LOB，也被稱爲正面）：

  優點：非常靈活。與EAV設計模式相比，保持必要連接的數量較低。易於更新/添加/刪除每個產品的數據，但很難保持數據完整性，無需額外的表。

  缺點：所有排序將由應用程序而不是數據庫完成。當大量數據集被大量用戶處理時，會使用大量性能（內存？）。

我們的主要問題：

• 哪種模式/結構，你會使用，或者甚至一個不同的解決方案嗎？
• 現在有沒有比mySQL更好的數據庫來實現我們想要的？

非常感謝！

參考：How to design a product table for many kinds of product where each product has many parameters

Answer 1

爲什麼只限於一個模型？你很有可能會用兩種不同的模式，每種模式都很好地滿足特定的目標。

假設，通常情況下，兩者不一定是絕對即時同步的，你可能容易得到更好的整體性能。你對同步有什麼樣的硬性要求？毫秒達1分鐘？

Udi Dahan有一些關於命令查詢責任分離（CQRS）的good information。另見otherarticles。 InfoQ也有來自QCon08的Greg Young的relevant video。

編輯：Here's another video（由烏迪達漢），討論，除其他外，多種模式的好處。

Answer 2

的MySQL即使是非常大的數據集有很好的表現。我在一家金融服務SaaS公司使用它，它一直運行良好。我還將SQL Server和Oracle用於非常大型的應用程序，並且MySQL在整體上表現不會更好或更差。不過，我的重點更多的是業務層面，而且您可能會從距離數據庫較近的人那裏獲得更詳細的意見。

選擇模式時，請記住，比數據層擴展應用程序層要簡單得多（添加應用程序服務器很簡單，而且便宜）。對常見操作執行許多連接可能會導致真正的性能瓶頸。

我會建議你爲兩種方法建立原型，這樣你們可以更熟悉它們中的每一種，並在特定環境中對它們的性能進行基準測試。

此外，您可能希望查看SQL的替代方法，嘗試實現類似於您概述的模式的模式。一家非常大型的知名互聯網公司的朋友開始使用Project Voldemort。他更喜歡這種類似的努力，這主要是由於這個非常活躍的社區。

Answer 3

從您的解決方案看來，您似乎不想使用關係模型，因此最好不要使用關係數據庫，請查看以下替代方案：http://nosql-database.org/ btw SQLServer具有很好的SLOB功能，形式爲xml字段（可以通過XQuery進行索引查詢）