社交网站 用户表 建表字段问题

一个小白问题，问问大家都怎么做的。
一个User用户，一个Blog表，一个Picture表，一个Friend表……等等，为用户提供博客、相册、好友等功能。
要求用户登录后显示其博客数、照片数、好友数等。。
这些字段是建在User表里，每次增减博客、照片、好友后更新好呢？
还是每次登录运行3个select count(*) from xxx；好？//如果记录太多是不是效率和对数据负担太大
大家一般怎么弄？

13 个解决方案

#1

用 select count(*) 吧，这个容易保持一致。

#2

引用 1 楼 ACMAIN_CHM 的回复:

用 select count(*) 吧，这个容易保持一致。

如果博客表、照片表、相片表记录数非常大了，每次登录要遍历这么多个表性能会不会很有问题？
或者在User表添加字段，然后用触发器来修改？

#3

你觉得用触发器来修改效率会高？ 

#4

引用 2 楼 kamouswjw 的回复:

Quote: 引用 1 楼 ACMAIN_CHM 的回复:

用 select count(*) 吧，这个容易保持一致。

如果博客表、照片表、相片表记录数非常大了，每次登录要遍历这么多个表性能会不会很有问题？
或者在User表添加字段，然后用触发器来修改？

为这些表中的user表引用字段添加索引
比如Blog表有一个userid外键引用了user，为userid添加索引，当你count(*) where userid=xxx的时候只查询索引表不会查询Blog表。

#5

我会把"每页显示多少条记录"放在user表。总数的话，也可以吧。
添加好友后，也是需要count(*)让后再update.
这个和加载页面的时候count(*)我觉得效率上没啥区别。
可能用户在添加好友后慢一下会觉得正常，而页面刚加载的时候慢就觉得不适应吧。

#6

社交网站一般不都是用内存数据库么。。

#7

引用 4 楼 yousteely 的回复:

Quote: 引用 2 楼 kamouswjw 的回复:

Quote: 引用 1 楼 ACMAIN_CHM 的回复:

用 select count(*) 吧，这个容易保持一致。

如果博客表、照片表、相片表记录数非常大了，每次登录要遍历这么多个表性能会不会很有问题？
或者在User表添加字段，然后用触发器来修改？

为这些表中的user表引用字段添加索引
比如Blog表有一个userid外键引用了user，为userid添加索引，当你count(*) where userid=xxx的时候只查询索引表不会查询Blog表。

恩。这个方法效率就高些了……

#8

引用 5 楼 xuboke 的回复:

我会把"每页显示多少条记录"放在user表。总数的话，也可以吧。
添加好友后，也是需要count(*)让后再update.
这个和加载页面的时候count(*)我觉得效率上没啥区别。
可能用户在添加好友后慢一下会觉得正常，而页面刚加载的时候慢就觉得不适应吧。

我觉得这样更好点，因为至少减少了每次登录后的查询sql条数，如果用户量很多一是sql效率问题，二是对数据库压力问题……
不知道专业社交网站怎么弄得。。

#9

引用 6 楼 huijianpang 的回复:

社交网站一般不都是用内存数据库么。。

内存数据库。。。
数据库缓存吧……

#10

引用 9 楼 kamouswjw 的回复:

Quote: 引用 6 楼 huijianpang 的回复:

社交网站一般不都是用内存数据库么。。

内存数据库。。。
数据库缓存吧……

engine=memory 的内存引擎数据库

#11

引用 9 楼 kamouswjw 的回复:

Quote: 引用 6 楼 huijianpang 的回复:

社交网站一般不都是用内存数据库么。。

内存数据库。。。
数据库缓存吧……

我说的是内存数据库，不是数据库缓存
redis，MongoDB

#12

引用 9 楼 kamouswjw 的回复:

Quote: 引用 6 楼 huijianpang 的回复:

社交网站一般不都是用内存数据库么。。

内存数据库。。。
数据库缓存吧……

比如微博，并发量非常大，并且是海量数据，但是咱们完全感觉不到延迟，发一个微博之后自己马上可以看到，过一会之后别人也可以看到，如果是直接访问的物理数据库，性能不会这么高。

一般的做法都是使用了内存数据库，具体是个什么样的架构，不是太清楚，但是可以知道的是：存取都是使用内存数据库，内存数据库和物理数据库之间有同步的机制。

#13

引用 12 楼 huijianpang 的回复:

Quote: 引用 9 楼 kamouswjw 的回复:

Quote: 引用 6 楼 huijianpang 的回复:

社交网站一般不都是用内存数据库么。。

内存数据库。。。
数据库缓存吧……

比如微博，并发量非常大，并且是海量数据，但是咱们完全感觉不到延迟，发一个微博之后自己马上可以看到，过一会之后别人也可以看到，如果是直接访问的物理数据库，性能不会这么高。

一般的做法都是使用了内存数据库，具体是个什么样的架构，不是太清楚，但是可以知道的是：存取都是使用内存数据库，内存数据库和物理数据库之间有同步的机制。

恩，微博的确反应非常快……可能是架构和数据库比较特殊。。
不过不是很多企业都用mysql深度定制的数据库。。而且那么大并发更要追求尽可能少访问数据库。。