第一个问题：
在大丰等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供成都网站制作、网站设计、外贸网站建设 网站设计制作按需开发网站,公司网站建设,企业网站建设,成都品牌网站建设,营销型网站建设,成都外贸网站制作,大丰网站建设费用合理。
对应关系是多对多，也就是一篇文章可以给多人收藏，一人可以收藏多篇文章，使用第二种方法，可以任意扩展，第一种方法虽然在取值的时候方便，但是其他的扩展操作会很痛苦
第二个问题解法跟第一种一样
第三个问题：
缓存的使用，避免过度查询同样的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 （又衍生出用户角色权限关系，还是另文讨论），业务也需要个人的个人信息如真实姓名、地址等也一股脑往上添加，现在形成了一个很完整的用户关系表。
