扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
第一个问题:
在大丰等地区,都构建了全面的区域性战略布局,加强发展的系统性、市场前瞻性、产品创新能力,以专注、极致的服务理念,为客户提供成都网站制作、网站设计、外贸网站建设 网站设计制作按需开发网站,公司网站建设,企业网站建设,成都品牌网站建设,营销型网站建设,成都外贸网站制作,大丰网站建设费用合理。
对应关系是多对多,也就是一篇文章可以给多人收藏,一人可以收藏多篇文章,使用第二种方法,可以任意扩展,第一种方法虽然在取值的时候方便,但是其他的扩展操作会很痛苦
第二个问题解法跟第一种一样
第三个问题:
缓存的使用,避免过度查询同样的sql,如果你的系统重复查询很少,你用缓存也没什么用,如果多,用缓存会快很多,你看你使用的情况,自己衡量什么时候该用
1.建立用户信息表
create table userinfo(id int(4) not null primary key, name varchar(20) not null unique key)engine=innodb default charset=utf8;
2.建立好友关系表
create table friend(uid int(4) not null, foreign key(uid) references
userinfo(id),fid int(4) not null, foreign key(fid) references
userinfo(id),unique key(uid,fid))engine=innodb default charset=utf8;
3.追加测试数据(满足uidfid条件)
insert userinfo values(1111---9999,'namea---namei’);
insert friend values(1111,4444---6666);
insert friend values(5555,6666---9999);
4.查询好友(5555的好友)
select * from friend where uid=5555 or fid=5555;
+-------+------+
| uid | fid |
+-------+------+
| 1111 | 5555 |
| 5555 | 6666 |
| 5555 | 7777 |
| 5555 | 8888 |
| 5555 | 9999 |
+-------+--------+
5.问题:
5.1.userinfo中的id和name不为null,且不可重复:table设计可以做到
5.2.friend中的uid和fid均不为null,且都来自于userinfo的id:table设计可以实现
5.3.(uid,fid)组合不可重复:table设计可以完成
5.4.好友关系的表达时,(1111,5555)和(5555,1111)有冗余,也会出现(1111,1111)这样的数据:这个在table设计实现比较麻烦,需要在程序层面实现,也即增加限制条件uidfid即可
6.结果:
table设计达不到要求,或者较难达到要求时,可以在程序层面予以弥补。
说起用户表,大概是每个应用/网站立项动工(码农们)考虑的第一件事情。用户表结构的设计,算是整个后台架构的基石。如果基石不稳,待到后面需求跟进了发现不能应付,回过头来反复修改用户表,要大大小小作改动的地方也不少。与其如此,不妨设计用户表之初就考虑可拓展性,争取不需要太多额外代价的情况下一步到位。
先前设计:
id
username
password
用户名加上密码,解决简单需求,留个id作为其他表的外键。当然,那时候密码还可能是明文存储,好点的知道md5。
后来呢,随着业务需求的拓展,要加个用户状态 status 判断用户是否被封禁,注册时间和注册IP地址、上次登录时间和IP地址备查(并衍生出登录记录表,用来判断是否异地登录等,在此不表),用户角色/权限 role (又衍生出用户角色权限关系,还是另文讨论),业务也需要个人的个人信息如真实姓名、地址等也一股脑往上添加,现在形成了一个很完整的用户关系表。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流