这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记。
本次青训营我参与的组队大项目是极简版抖音的服务端实现。本篇文章将主要围绕项目中涉及到的数据库表设计进行讨论。
对于现实生活中的用户、视频等实体，我们可以将其抽象为数据库中的表，将对实体的一些操作转换为对数据库中表的增删改查。实体拥有属性，对应到数据库就是表拥有字段（列）。实体与实体间存在数量上的关联关系，比如1:1（一对一）、1:n（一对多）、m:n（多对多）的关系。举一些本项目中的具体例子：一个短视频，一定由且仅由一个用户进行发布，而一个用户可以发布0到多个短视频，那么就应该在“短视频”表中加一个“用户ID”字段，作为外键，关联到“用户”表；一个用户可以给0到多个短视频点赞，一个短视频可以被0到多个用户点赞，那么就应该新建一张“点赞”表，这张表中有“用户ID”、“视频ID”两个字段。
当然，这里不应该使用数据库层面的外键，而是应该在应用层实现外键概念，原因主要有以下几点：（1）增加数据库服务器压力，容易让数据库部分成为整个系统的性能瓶颈，而数据库部分又不像业务部分，可以方便地进行水平扩展，直接通过增加机器数量来提升对外的整体性能；（2）在数据库进行水平分表或分库时，外键其实就失效了，白白浪费存储空间；（3）在高并发、大流量场景下，由于需要跨表查询、去获得另一张表的锁，所以更容易引发死锁。
另外，点赞数、评论数这种字段，其本质是一种导出字段，也就是说可以由其他字段计算得来，所以有两种实现思路：一种是将其作为一个单独的字段作为实体的一个属性，另一种就是每次要获取时重新进行计算，
