㈠ 聊天软件的数据库设计
简单的设计如下：如需其他功能，需要扩展，
用户（主键，账号，密码，邮箱，..）
好友关系（所属者ID，好友ID）
聊天记录（主键，所属者ID，好友ID，时间，内容，..）
create table users
(uid number not null primary key,
uname varchar2(50) not null,
pwd varchar2(20) not null,
email varchar2(50) not null,
...)
create table friends
(owerid number not null,
friendid number not null,
constraint fk_owerid poreign key(owerid) references users(uid),
constraint fk_friendid poreign key(friendid) references users(uid),
constraint pk_friendid_owerid primary key(owerid,friendid)
)
create table records
(rid number not null primary key,
owerid number not null,
friendid number not null,
rdate date default sysdate,
rcontents varchar2(4000),
constraint fk_owerid_r poreign key(owerid) references users(uid),
constraint fk_friendid_r poreign key(friendid) references users(uid),
..
)
㈡ 聊天系统的好友列表数据库如何设计
对于关系数据库，可以设一个这样的字段，这个字段里存放了李四的所有好友，每个好友以“，”分隔；
对于非关系数据库，比如说健值消岩数据库，可以使用一个大型的HASH表来拿衡御存放，拦洞李四的所有好友以一个链接的方式串起来 。
比如:
linker表示链接
hash(李四)=linker(王五、张三、黄光、李明)
㈢ 微信朋友圈数据库模式如何设计的
其实微信朋友圈的数据库设计模式无非就是符合了三种设置模式，其中最常用的是第三种。
第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。
第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。
第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。
㈣ 聊天系统-数据库设计
采用Redis进行数据存储，主要包括频控、限流、用户表、在线用户表、聊天消息表（redis list实现消息队列）、好友表（TODO）
CheckFrequency(userId uint64) bool
返回true检查通过，false触发频控
visited_{user_id} >3触发
离线用户key为空
数据结构：key-value
取值：
1=在线
2=离开
3=隐身（VIP功能）
数据结构：list
数据结构：hashmap
㈤ 利用JavaWeb设计简易聊天室，具体要求看补充
利用JavaWeb设计简易聊天室
这样你什么柑橘
比较
㈥ 论坛站内信群发，数据库设计该如何优化
真正的大数据保存在 信息表中， 关联表式很小的，虽然随着系统的运行数据会很多 ！！
有两种方案解决：
1， 及时加载策略：每群发一条消息自然会往消息表中插入一条数据，这时你可以同时往关联表中插入数据。 好样的，问题来了！如果系统用户几百万，你发一条站内信，就要往关联表中插几百万条数据，这是很耗性能的！！
2，延迟加载策略：每群发一条消息自然会往消息表中插入一条数据，不要及时插入到关联表。只当用户登录站内信时， 我才将消息表中的未读消息加载进来。
㈦ 简述数据库应用系统的设计步骤
数据库设计的基本步骤：
1、系统需求分析与设计。
2、概念结构分析与设计。
3、逻辑结构分析与设计。
4、物理结构分析与设计。
5、系统实施。
6、系统维护。
(7)群聊数据库设计扩展阅读：
数据库设计技巧：
1、原始文件与实体的关系
它可以是一对一，一对多，多对多的关系。一般来说，它们是一对一的关系：一个原始文档只对应于一个实体。在特殊情况下，它们可以是一对多或多对一关系，即一个原始文档对应于多个实体，或者多个原始文档对应于一个实体。
这里的实体可以理解为基本表。在对应关系明确后，对输入接口的设计非常有利。
2、主键和外键
一般来说，实体不能既没有主键也没有外键。在E－R图中，叶中的实体可以定义主键或不定义主键（因为它没有子代），但它必须有外键（因为它有父项）。
主键和外键的设计在全局数据库的设计中起着重要的作用。当全球数据库的设计完成后，一位美国数据库设计专家说：“钥匙无处不在，只有钥匙。”。这是他数据库设计的经验，也体现了他对信息系统核心（数据模型）高度抽象的理念。
因为：主键是一个高度抽象的实体。主键和外键的配对表示实体之间的连接。
3、基本表的属性
基本表不同于中间表和临时表，因为它具有以下四个特点：
原子性。基本表中的字段不可分解。
原始主义。基本表中的记录是原始数据（基本数据）的记录。
演绎的。所有输出数据都可以从基本表和代码表中的数据导出。
稳定。基本表的结构比较稳定，表中的记录要长期保存。
在了解基本表的性质之后，在设计数据库时，可以将基本表与中间表和临时表区分开来。