目前主流 cms 的数据库设计里，把文章分成两个表，一个表只包含 id 和 content，一个表包含其他字段（如标题，日期，作者，类别。。。），这么做的好处是什么呢？直接在一个表里，不是更方便吗？

[noea]

是方便数据量大的话再进行分表。

[lavadore]

方便扩展，添加各种插件不需要修改文章主表了，另外数据量大了后效率也比一个表要高

[kchum]

content 可大可小，其他字段可以预见。放在一起，这个表体积更大，影响效率。

[qiayue]

因为 content 只有在详情页面才需要取出来，更多的时候在文章列表中我们只需要标题作者之类的信息，这样可以更快的取出数据。

[chenjf2k]

个人建议，一般情况不需要分表，分表多数用来装 B 。

[qiayue]

@chenjf2k 个人博客不需要，但是公司产品你不分试试，我们一个 APP ，日活才几万就感觉以前不分表简直就是脑子进屎了

[chenjf2k]

@qiayue 具体情况需要具体分析，就我公司开发电商 ERP 的经验来讲，一般（低于 50 字段）分不分表没感觉有什么问题。

[66beta]

wordpress 分得就蛮好的

[FrankFang128]

元数据和详情

[dbfox]

赞这种方式，

行的总字节数越少，查询速度越快，而 content （一般来说数据比较多一点）
如果使用了 orm 读一条文章信息，会磁盘 IO 会比较大

[ipconfiger]

就现在普遍使用 orm 的情况下，分表无疑效率要高一些，不用 orm 的话，可以通过避免 select * 来规避结果集输出无用信息，但是在使用 orm 的时候谁会吃多了这么干，那不是比写 SQL 更麻烦么。


@chenjf2k 经验主义的坏处在于适用性窄，贵司的电商 ERP 的数据量级不知能否透露，不然对楼主误导很大，因为楼主也没说他要的 CMS 是哪个量级的

[chenjf2k]

@ipconfiger
我查了订单表（ 80 个字段）， 21 万条记录。不用 ORM 。

[chenjf2k]

运行半年，数据量还不算大。

[ipconfiger]

21W 这个量级，只能用 tiny 来形容，没感觉是应该的，之前把开房记录导入数据库做了个查询也都是上亿的数据量级呢

[refresh]

@chenjf2k 21 万量级太小，超过百万再谈分表

[lavadore]

@chenjf2k 楼主已经说了是 cms 了，请先搞清楚。

[chenjf2k]

感觉大家的热情很高，超过群主。呵呵~，
也许是我说重了点：“分表用来装 B ”，触动大家的痛处。
好吧，我赞同：分表很有用，特别是大数据级的，一定要分清楚。

[2015813]

分表是为了几何级数据量考虑的，有远见的 cms 都这么干！

[jsq2627]

没接触过大型数据库。表示不理解为何字段数量会影响查询性能。不是应该是记录数量影响性能吗？楼上可以说说字段过多性能瓶颈在哪里吗？

[jsq2627]

@ipconfiger 高级的 orm 还是能很好的控制 select 过程的

[ipconfiger]

@jsq2627 很麻烦的，还不如写 raw sql 了

[phoenixlzx]

看过一眼 NodeBB 的数据库，就一个 objects collection

... 虽然不是 SQL 不过也算是什么玩意都揉一起了...