哪個更有效率：一個長單表還是分佈表？爲什麼？

這個問題是關於性能，如果答案是特定於我提供的情況，我將不勝感激。哪個更有效率：一個長單表還是分佈表？爲什麼？

哪種性能更合適？

創造了太多的領域
創建多個表和分發類似領域對他們

情況的表：一個廣泛的Web內容管理系統模塊

模式1：長但一張桌子

cms 
----------------------------------------------- 
Id 
Title 
Description 
Images 
Order 
Status 
Publish 
meta_keywords 
meta_description 
meta_author

Cleary，大多數像joomla這樣的開源CMS使用上述模式。但我認爲，該模式是殺死RDBMS的精神。我們可以輕鬆地將特定文章的內容，配置和元數據分離到不同的表格中。像下面

模式2：很多，但相關的表

Cms_content   cms_meta  cms_configuration 
--------------------------------------------------------------------------- 
Id     id    id   
Title    content_id  content_id 
Description   keywords  status 
Content    description  order 
Images    author   publish

注：在這種情況下，關係是一對一個

哪個是正確的模式可循？爲什麼選擇一個長而一張表，或者爲什麼不選擇分佈表，在單個表上？

來源

2011-12-27 Starx

「適當」總是取決於目標和使用情況。沒有銀彈 – zerkms

@zerkms，同意這就是爲什麼我也提供了一個案例:) – Starx

哦，你的意思是這是一個「案件」。好。任何理由將**單個**實體分解爲多個部分？字段屬於同一個實體，這個模式完成它的工作。所以，不要碰那些有用的東西;-) – zerkms

唯一可能的合理原因有非規範化的數據（包含多列一個表），我能想到的是：

懶惰書面SQL JOIN小號
在讀語句可能的性能改進

我喜歡去規範版本所有的時間，這是因爲：

我可以肯定的數據完整性
我可以從數據庫中提取易信息（例如，有多少帖子有一些元，有多少不同的METAS有等）

來源

2011-12-27 10:27:30

你爲什麼說'非規範化的數據（一個有很多列的表）'？所有的字段都屬於**相同的實體**。所以單個表格**也被標準化了**也是 – zerkms

確切地說，當您剛剛列出文章時，爲什麼還要關心閱讀元素。 – Starx

@Starx：不要通過在'SELECT'中指定需要的精確字段來讀取metas。 – zerkms

我覺得關鍵性能關於'現代' - 我不太瞭解'現代'的含義，但是 - 基於RDBMS的應用程序不僅取決於數據庫架構。

數據庫設置：內存使用策略，關鍵的緩衝區大小，查詢緩存大小等數據
分發/處理：分割，網格處理。
緩存策略：使用嵌入式緩存引擎或其他（如memcached）。
硬件性能

因此，估計性能不是一個簡單的問題。即使是一個有100個字段的表格也可以安裝在內存中，但即使是兩個字段的表格也不能。對於5M行的查詢可以在一分鐘內完成，但有時相同的查詢不會在10M行上結束10分鐘（只有兩次！） - 這取決於上面提到的環境。

因此，我認爲我們不能選擇整個案例的最佳做法。就你的例子而言，關鍵在於DBA的口味。（不是笑話）

來源

2011-12-27 11:01:03 lqez

我不明白這個部分，「關鍵在於DBA的味道」。由於它不是玩笑，請解釋一下 – Starx

這些表格不會通過「劃分」進行很好的優化。因爲表格之間只有1：1的關係。關於分割，我同意@TudorConstantin，但我認爲打破一個可能將表格分成3個表格或5個表格或10個表格不是性能問題。此外，這不是一個龐大的數據庫聚合，地圖/減少，分析或類似網格的應用程序，對嗎？所以，我寫了'這是DBA的品味'。 – lqez

哪個更有效率：一個長單表還是分佈表？爲什麼？

回答

相關問題