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

时间:2022-10-15 14:54:41
一个小白问题,问问大家都怎么做的。
一个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深度定制的数据库。。而且那么大并发更要追求尽可能少访问数据库。。

#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深度定制的数据库。。而且那么大并发更要追求尽可能少访问数据库。。