哪个更有效：一张长单表还是分布式表？为什么？答案

【问题标题】：Which is more efficient: One long Single Table or Distributed Table? and Why?哪个更有效：一张长单表还是分布式表？为什么？
【发布时间】：2011-12-27 10:17:53
【问题描述】：

这个问题是关于性能的，如果答案是针对我提供的案例的，我将不胜感激。

哪个更适合性能？

创建包含太多字段的表
创建多个表并向它们分配相似的字段

案例：一个广泛的网络 CMS 模块

模式 1：长但只有一张桌子

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

很明显，大多数像 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

注意：这种情况下的关系是一对一的

应该遵循哪种模式？为什么选择一张长但只有一张桌子，或者为什么不选择分布式桌子而不是一张桌子？

【问题讨论】：

“正确”总是取决于目标和使用情况。没有灵丹妙药
@zerkms，同意这就是我也提供案例的原因:)
哦，你的意思是这是一个“案例”。好的。有什么理由将 single 实体拆分为多个部分？这些字段属于同一个实体，这个模式可以完成它的工作。所以不要碰有用的东西;-)
@zerkms，我不知道，这就是我问的原因。但在我看来，一是为了可管理性，二是为了效率。当我显示一篇文章的内容时，我不需要导入配置或元部分。或者可以说，当我只更新状态时，我不需要触摸其他两个表，从而给服务器带来更小的工作量。附言只是一个意见...我不是这方面的专家...
我认为database normalization 的规则定义得很好，并为数据库设计提供了既定的指导方针。为了便于使用和提高性能，在需要时通过视图等进行反规范化也是一种常见做法。

标签： mysql database-design

【解决方案1】：

我能想到的具有非规范化数据（一个表有很多列）的唯一可能的合理原因是：

懒惰写SQLJOINs
读取语句的可能性能改进

我一直喜欢使用标准化版本，因为：

我可以确保数据完整性
我可以轻松地从数据库中提取信息（例如，有多少帖子有一些元，有多少不同的元等）

【讨论】：

你为什么这么说denormalized data (one table with many columns)？所有字段都属于同一个实体。所以单表也被规范化了
没错，当您只是逐条列出文章时，为什么还要关心阅读元数据。
@Starx：不要通过在SELECT中指定您需要的确切字段来读取元数据
@Tudor Constantin: 哦，还有图片 :-S 如果它是一个序列化的字符串 - 那么你是绝对正确的，对不起，+1
@Starx：在真正需要之前不要优化。过早的优化 bla-bla-bla，你知道的 ;-)

【解决方案2】：

我认为性能的关键在于“现代” - 我不太了解“现代”的含义，但是 - 基于 RDBMS 的应用程序不仅依赖于数据库模式。

数据库设置：内存使用策略、key buffer大小、查询缓存大小等
数据/处理分布：分区、网格处理。
缓存策略：使用嵌入式缓存引擎或其他（如 memcached）。
硬件性能

因此，估计性能并不是一个简单的问题。即使是一个有 100 个字段的表也可以放入内存中，但即使是两个字段的表也可能不能。 5M 行的查询可以在一分钟内完成，但有时同一查询不会在 10M 行上结束 10 分钟（只有两次！） - 这取决于我上面提到的环境。

因此，我认为我们不能为整个案例选择最佳实践。对于您的示例，关键在于 DBA 的品味。（不是开玩笑）

【讨论】：

我不明白这部分，the key is dangled on DBA's taste。既然不是玩笑，请解释一下
这些表通常不会通过“划分”得到很好的优化。因为表之间只有 1:1 的关系。关于划分，我同意@TudorConstantin，但我认为将一个可能的字段表分成 3 个表或 5 个表或 10 个表对性能来说并不是一个大问题。而且，这不是一个用于聚合、map/reduce、分析或类似网格的应用程序的大型数据库，对吧？所以，我写了It's DBA's taste。