目前主流 cms 的数据库设计里，把文章分成两个表，一个表只包含 id 和 content，一个表包含其他字段（如标题，日期，作者，类别。。。），这么做的好处是什么呢？直接在一个表里，不是更方便吗？
akaayy · 2015-09-15 09:25:36 +08:00 · 9404 次点击这是一个创建于 3364 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
noea 2015-09-15 09:27:39 +08:00  1
是方便数据量大的话再进行分表。
|
 |
2
lavadore 2015-09-15 09:29:14 +08:00 1
方便扩展，添加各种插件不需要修改文章主表了，另外数据量大了后效率也比一个表要高
|
 |
3
kchum 2015-09-15 09:29:23 +08:00 via iPhone 1
content 可大可小，其他字段可以预见。放在一起，这个表体积更大，影响效率。
|
 |
4
qiayue 2015-09-15 09:31:43 +08:00 1
因为 content 只有在详情页面才需要取出来，更多的时候在文章列表中我们只需要标题作者之类的信息，这样可以更快的取出数据。
|
 |
5
chenjf2k 2015-09-15 09:32:05 +08:00 1
个人建议，一般情况不需要分表，分表多数用来装 B 。
|
|
7
chenjf2k 2015-09-15 09:45:56 +08:00
@qiayue 具体情况需要具体分析，就我公司开发电商 ERP 的经验来讲，一般（低于 50 字段）分不分表没感觉有什么问题。
|
 |
8
66beta 2015-09-15 09:47:22 +08:00 1
wordpress 分得就蛮好的
|
 |
9
FrankFang128 2015-09-15 09:49:23 +08:00 1
元数据和详情
|
 |
10
dbfox 2015-09-15 09:50:46 +08:00 1
赞这种方式，
行的总字节数越少，查询速度越快，而 content （一般来说数据比较多一点） 如果使用了 orm 读一条文章信息，会磁盘 IO 会比较大 |
 |
11
ipconfiger 2015-09-15 09:53:45 +08:00 1
就现在普遍使用 orm 的情况下，分表无疑效率要高一些，不用 orm 的话，可以通过避免 select * 来规避结果集输出无用信息，但是在使用 orm 的时候谁会吃多了这么干，那不是比写 SQL 更麻烦么。
@chenjf2k 经验主义的坏处在于适用性窄，贵司的电商 ERP 的数据量级不知能否透露，不然对楼主误导很大，因为楼主也没说他要的 CMS 是哪个量级的 |
|
12
chenjf2k 2015-09-15 10:08:32 +08:00
@ipconfiger
我查了订单表（ 80 个字段）， 21 万条记录。不用 ORM 。 |
|
13
chenjf2k 2015-09-15 10:09:11 +08:00
运行半年，数据量还不算大。
|
|
14
ipconfiger 2015-09-15 10:10:09 +08:00
21W 这个量级，只能用 tiny 来形容，没感觉是应该的，之前把开房记录导入数据库做了个查询也都是上亿的数据量级呢
|
|
17
chenjf2k 2015-09-15 10:32:56 +08:00
感觉大家的热情很高，超过群主。呵呵~，
也许是我说重了点：“分表用来装 B ”，触动大家的痛处。 好吧，我赞同：分表很有用，特别是大数据级的，一定要分清楚。 |
 |
18
2015813 2015-09-15 12:01:16 +08:00 via iPhone
分表是为了几何级数据量考虑的，有远见的 cms 都这么干！
|
 |
19
jsq2627 2015-09-15 13:59:41 +08:00 via iPhone
没接触过大型数据库。表示不理解为何字段数量会影响查询性能。不是应该是记录数量影响性能吗？楼上可以说说字段过多性能瓶颈在哪里吗？
|
|
20
jsq2627 2015-09-15 14:02:03 +08:00 via iPhone
@ipconfiger 高级的 orm 还是能很好的控制 select 过程的
|
|
21
ipconfiger 2015-09-15 14:12:27 +08:00
@jsq2627 很麻烦的，还不如写 raw sql 了
|
 |
22
phoenixlzx 2015-09-15 20:43:26 +08:00
看过一眼 NodeBB 的数据库，就一个 objects collection
... 虽然不是 SQL 不过也算是什么玩意都揉一起了... |
Select Language