项目介绍
我们的项目是基于跨层优化的视频传输系统，在dash架构的基础上实现视频的流畅播放，构建一个供用户交流的视频分享平台。
设计思路
我们小组根据前期的需求文档和原型等资料，模拟开发和使用的场景，初步确定了12个表，其中服务器端9个表，客户端3个表。首先从功能出发，最先能确定的是视频表，视频下有评论区所以需要评论表去储存用户评论内容，举报功能要求举报表，举报需要举报类型标识所以有个举报表，用户上传的视频要经过审核，如果从视频表中搜索效率会很低，所以我们根据实际情况创了一个审核视频表（缓冲表），属性基本跟视频表一样，但是为了避免冗余问题，去掉了部分属性。然后就是举报表，由于我们有三种举报类型，同时为了满足三大范式，我们建立了举报和举报类型表，将三种范式统一表示。而在在相似的评论表中因为只存在两种不同状态，所以我们没有额外建立类型表。
接着从角色角度出发，用户登录注册以及个人信息的记录需要一个用户表，但用户里有些特殊角色，包括VIP和管理员，我们针对他们建立了权限类型表，该表不仅能起区分角色，也能起权限控制的作用。以此类推确定了所有的表。然后建立了满足基本功能需要的视频表，历史记录表，图片表。
最后确定每个实体之间一对一、一对多以及多对多的关系画ER图，并且在此过程中注意了表名，属性名的命名规范和属性的数据类型，同时保证了设计符合三范式。
值得一提的是由于我们大部分表的增删改查操作比较频繁，所以我们除了与类型表的关联之外统一没有使用外键，取而代之的是改用索引的方式，加快操作速度，支持大规模数据的情况，由于实现操作过于细节，这儿不加赘述。
整体PDM
服务器：
客户端：
设计心得
- 数据库设计要从需求出发，结合实际。数据库建立的目的是服务项目。数据库各个表的建立，表内属性的规划，都要便于实际开发。
- 数据库设计需要细心和耐心，从实体出发。在设计初期不能遗漏表和属性，设计结束后还要检查是否有冗余属性。
- 有些表和字段需要仔细推敲，小组成员有不同意见时要积极交流，深入沟通，往往能发现问题所在。
- 要多沟通，与同学、老师和项目参与方沟通，确保数据库设计符合规范，符合实际。
- 数据库设计要求对项目有整体、全面的认知，否则设计时会无从下手。
- 用户上传的视频要经过审核，如果从视频表中搜索效率会很低，所以我们根据实际情况创了一个审核视频表（缓冲表）。
- 由于用户可能需要离线观看视频，我们将快速登录表和离线缓存表置于用户本地客户端。
- 用户举报的类型有三类，但数据并不复杂，因此我们将三种举报行为合并放在一张表里，再通过类型属性标识。
- 将外键改为索引的方式大有裨益，在大规模项目开发中很有帮助