我們在mySQL Workbench的幫助下爲新應用程序構建了數據庫結構，並且使數據列表所需的聯接數量急劇增加，一對多的關係增加。數據庫結構 - 加入或不加入
該應用程序將會非常繁重，每個表格有幾十萬行。
的問題：
是不是真的那麼糟糕合併在需要的表，從而減少連接？
我們應該開始尋找水平分區嗎？ （結合合併表）
是否有更好的方法，然後透視表來照顧多對多的關係？
我們討論了將所有數據存儲在序列化的文本列中，讓應用程序進行排序而不是數據庫，但這看起來像是一個非常糟糕的主意，儘管數據庫將被大量緩存。你怎麼看？
請使用數據庫的規範化形式。對於大部分任務，您不需要超過3或4個聯接，並且您仍然可以爲最常見的聯接編寫視圖。反規範化將讓您在更改一個屬性時始終考慮更新多個地點/表中的字段，並且肯定會導致更多問題而不是收益。
如果您擔心報告性能，那麼您仍然可以將定時批量的數據提取到單獨的表中，以獲得報告查詢所需的性能。如果這是爲了簡化查詢，您可以使用視圖。
一如既往，它取決於您的應用程序，但總體而言，過多的反規範化會稍後再回來並咬你。一個良好的規範化數據庫意味着你應該能夠以大多數方式查詢你的數據，你以後可能會需要，尤其是報告（通常是事後的報告）。
如果你將所有的數據都保存在序列化的文本列中，並且你的客戶端要求報告顯示所有具有特定屬性的行，那麼你將不得不做一堆字符串操作來獲取這些數據。
如果你擔心太多的加入爲你的查詢，你可以考慮暴露某些組數據的看法...
相反的順序：
算了。使用數據庫。人們說，「在應用程序中使用它」通常是那些對寫入數據庫的工作量無知的人。
取決於確切的需要。
取決於確切的需要。 OLTP（交易處理） - 用於Firth標準格式。 OLAP（分析處理） - 尋找適當的星形圖和非規範化以獲得最佳性能。混合 - 忘記它。不適用於較大的安裝，因爲理論是不同的......除非您創建數據庫OLTP，然後使用特殊的OLAP多維數據集數據庫（mySQL沒有）。
數據庫旨在處理大量的連接。使用此功能可以使數據庫中的多種數據操作變得更容易。否則，爲什麼不使用平面文件？
我一直被告知要重新規範化，標準化和規範化。然後，我所告訴的連接數量增加，很快就會殺死性能。 – Industrial 2010-03-22 10:26:39
當數據集增長時，太多連接會導致性能下降。數據庫顯然有許多其他的優點，比做連接的能力.. – Kimble 2010-03-22 10:32:33
@Kimble：當然取決於應用程序，但你在哪裏畫「有太多連接」的線？ – Industrial 2010-03-22 10:50:54
除非您有明確證據表明由於連接而導致性能受損，否則請保持標準化。否則，正如其他人所說，你將不得不擔心多個更新。
特別是如果數據庫被大量緩存，就像您說的那樣，您會驚訝DBMS在做這種事情上有多快 - 畢竟這是它的設計目的。除非它是那種需要特殊性能優化的怪物應用程序，並且需要特殊的性能優化，否則您會發現保持開發，測試以及後續維護工作將變得更加重要。
加入是好的，通常不壞。它們允許您將數據保留在應有的位置，從而爲您提供最大的靈活性。
正如已經多次說過的，過早的優化通常是不好的，不好的。
嗯，我們不是在構建新的Facetube，但我們真的不想從一開始就構建一個將會遭受糟糕結構的應用程序。你認爲什麼時候合併表格並將它們彼此分開？ – Industrial 2010-03-22 10:46:55
@Industrial - 非正常化的時間通常是在您有明確證據需要時。除此之外，在優化時，試圖猜測哪裏比DBMS好，可能會導致「第一天糟糕的結構」。 – ChrisA 2010-03-22 16:25:34
如果你確定索引外鍵（你沒有設置外鍵？）並且在查詢中有合適的where子句，10-15個連接應該很容易被數據庫處理。特別是有這麼幾排。我有許多聯繫表上有數百萬行的查詢，他們運行良好。
通常，對數據進行分區比對非規範化要好。至於denomerizing去，除非你也制定了一個策略，保持非規範化的數據與父表同步的策略。
至於你是否真的需要這麼多的表格，或者如果你的設計不好，那麼我們可以對此進行評論的唯一方法就是如果我們看到表格結構。
謝謝！我們實際上已經在8-9連接的範圍內，並且肯定會增加核心，因此未來10-15個連接可能不是完全不可能的。 – Industrial 2010-03-22 10:22:54
開始正常化。定義您對性能的要求。測量。如果您沒有表現出色，則戰略性地解除標準化，直到您達到您的要求。 – 2010-03-22 10:48:29