首先 每一个QQ号都存于数据库表中, 这个表我这里用User表代替 里面的字段名有
用户的id qq号 好友表编号 同事表编号 群表编号 等等
当用户添加好友的时候 首先找到好友的qq号 将其插入到 User 表中的好友表编号 就行了
即 每个qq用户都应该有 一个好友表 这个表有编号 User里面存的就是好友表的编号
个人理解 希望对你有所帮助,谢谢!肯定是一张表解决啦
好友是用户的子集,你只要在用户表后面加一个字段,例如:用户类别(type)就行了,这样既方便,又便于扩展,以后要是有什么 陌生人、黑名单、爱人、老婆之类的分类,只要设置type不同就OK了
当然,最合适的设计就是下面的,我只给出类
class User{
private Integer id;
private String userName;
private String password
private UserType userType;
}
class UserType{
private Integer id;//编号,便于在页面中传递
private typeName;//类别名称,例如:好友,陌生人,老婆之类的
private remark;//备注
}
数据库设计
tbl_user
id int
username varchar
userpassword varchar
其他一些字段
userType_id int (这个关联tbl_userType表的ID
tbl_userType:
id int
name varchar
remark varchar当你把别人加入黑名单,在你这头看来,他是在黑名单列表里: 1、在他的QQ里,你的号不会消失,他可以看到你在线。 2、他给你发送消息,会被QQ后台的数据库拦截,你收不到他发的信息。 3、他可以查看你的QQ资料,你的更新信息(如Qzone日记更新)。 4、如果他的号下线以后再上线,你的号就不在他的好友里了。 黑名单可以让你永远避免被某人打扰,把一个好友或陌生人加到黑名单以后,他就再不能给你发信息,也不能发请求你加他为好友的信息了,除非你把他从黑名单里删除 基于上述原因,当你准备将好友列入黑名单时要慎重。
编辑本段加入黑名单后的特点:
1点QQ秀和她合影。能合影就没删,如果d出了不是对方好友,那就被删了。 2如果你被加入了黑名单,由于QQ好友列表未更新,对方QQ号仍在好友列表里,没隐身时点右键选择在线对其隐身;或者隐身时选择隐身对其可见,系统会告诉你没有这个好友。 3在群里,如果有加对方,你可以看到在线,但是你们在群里发的话相互都看不到,系统会自动屏蔽。 4进入你的QQ邮箱,在联系人中也可以看到,如果好友把你删了,联系人中会没有。 5被加入黑名单后,如果对方QQ空间有设置好友才能登陆的权限,你也是进不了的,因为已经不是好友了。 (补充:在QQ2010正式版中,自己被加入黑名单后,在群里还是可以看到对方的消息的。)
编辑本段如何把好友加入QQ黑名单(以QQ2009为例)
第一步——在你讨厌的QQ好友的头像上单击鼠标右键选择“移至黑名单”。 单击鼠标右键选择“移至黑名单”
第二步——在d出的对话框中选择“确定”。 在d出的对话框中选择“确定”。
第三步——然后你可以在“黑名单”中看到你的好友,图标会变成默认的QQ企鹅图标,昵称也将变成QQ号码,所有信息将不再更新。
具体请看: baikebaiducom/view/729346htm
参考资料:
就我个人的经验来说,数据库虽然在设计上确实需要有一定的经验,但是它并不是最难的。
对于数据的设计其实是对于现实中业务的一种抽象。
就我的习惯的话,我会先对于现实中的业务场景、业务的角色进行分析。
就拿一般的进销存系统来举例吧。
我有一个对于物料管理的仓库,我需要对我的物料的进销存进行管理。
那么我们就需要分析,没有系统的时候,人与人之间的业务是怎么流转的,他们都是通过哪些表单来进行流转的,上下级之间的消息传递和反馈都是怎么进行的。
当知道了业务以后,我们的数据库无非就是对于现实中的业务的一种具现。
对于业务的设计完成以后,就是针对角色的了。
例如:业务的传递都是在业务人员之间的,我们已经整理表单的传递,那角色其实就已经在这些传递中存在了。
但是,业务的角色是业务的角色,我们还要包括财务的角色,那对于财务来说,他需要在哪些环节看到这些业务的单据?并且需要怎么处理?财务的处理结果又包括哪些?不同的处理结果对于下一步的 *** 作又有什么影响。
当我们把这一切的逻辑整理完成后,我们对于数据库的功能上就已经满足了。
接下来的就是抽象数据的分类了。
例如:我们需要对不同的表进行一个分类,我个人喜欢把表分成三种,一种是基础数据表,一种是过程表,一种是结果表。
怎么解释呢?
基础数据表:顾名思义,就是对于基础数据的维护,哪些可以成为基础数据呢?就是我们的业务发生的各个过程中,这些数据都是可以参与其中的,这就是基础数据。
例如:货物的信息,客户的信息。
过程表:就是仅仅在一个过程中使用的表,当这个过程结束了,这个表就没用了。
例如:订单表,付款单表。他们表示的仅仅是订单从下单到最后关闭的这个过程,关闭以后,这个订单表其实我们就不会再去使用它了。
结果表:这个表的数据有一个特点,只允许添加,不允许删除和修改,这个表的数据本身就是对于一种最终结果的表现。
例如:日志表、账单表。
那我们在进行数据库设计的时候,就需要将这些使用情况考虑进去,将不同功能的表进行分离,尽量降低耦合,让相互表的修改不会影响使用。
例如:收款单,我们需要收一笔款的时候,就会生成这个收款单,当款收到后,这个收款单的功能就结束了。
但现实的情况中,可能财务收到了这笔钱,结束了收款单流程后,他发现填错了,本来应该收100,结果收款单写的110。
但是,收款单表示的是过程,当这个过程结束了,我们就不会再需要上一个收款单了,所以,按照我们业务的处理流程,我们应该先生成一笔冲抵的收款单,例如收到-110,然后再生成新的100的收款单。
我们每个月还会有财务统计报表,财务报表因为和现实中的财务账有关,是绝对不允许变动的,因此,这个财务报表就是一个结果表,我们会按月通过批处理程序,将收款单的明细和统计数据放到另一张表中,感觉好像比较冗余,但是这个确实非常必要的。
因为我曾经就遇到过一个情况,我们直接用过程表来进行数据的统计,然后11月30日有一笔收款已经完成了,结果发现收错了,就重新做了个收款单,结果本来已经出了11月结果的账单发生了变化,导致财务实际的处理出现了问题。
因此,数据的冗余有时候是有必要的,我们需要根据不同表的类型进行一些冗余的设计。
对于数据库设计的考虑点还有很多,可能一时半会儿也说不完,大家如果有什么好的思路,也可以在下方评论或关注我给我留言。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)