首先理一下主要的功能模块, 通过对功能关系的梳理, 整理出需要建的数据表:
- 所有文章列表 --- post 表
- 用户发表文章 --- user 表, 与 post 表是"一对多"的关系
- 用户购买文章 --- order 表, 与 post 表是"一对一"的关系, user 表与 post 表是"一对多"的关系
对于 user 表, 需要理解的是这里既有文章的作者, 又有文章的购买者, 因为一个用户登陆了, 不能因为身份的切换再切换账号, 这里需要在 user 表里用类似于 type 的字段区分. 然后, 作为作者的身份, 一个用户可以发布多篇文章, 所以与 post 表是简单的"一对多", 但是, 作为购买者的身份, 一个用户可以购买都篇文章, 而一片文章又可以同时被多个用户购买, 所以形成了二者是"多对多"的关系, 显然, 这里我们需要一个中间表, 我们把其定义为 order 表. order 表的首要作用是作为中间表存在的, 但是我在设计表结构的时候, 会为其增加几个冗余字段, 比如订单号, 文章标题等等. - 订单快照 --- order_items 表, 为了更好地记录每笔订单发生的时间, 价格等信息
- 系列教程 --- series 表, 除了单片文章, 还会有系列教程, series 表与 post 表是"一对多"的关系.
- 管理员表 --- admins 表
- 支付信息表 --- pay_logs 表, 用于记录与微信支付的相关信息
- 留言表 --- comments 表, post 表与 comments 表是"一对多"的关系, user 表与 comments 表也是"一对多"的关系
以上是基于对建表的需求做的分析, 下一篇会具体实现上述数据表. 哈哈, 这里我想吐槽一下我自己, 记得以前我跟着 laravel-china 上的项目教程学习的时候, 我也几乎都是闪过这些关于表格的说明的, 第一是觉得自己没有实操, 看着米有感觉, 二是觉得表述得都很通俗易懂, 这里是最可以快件的部分~~~ 但是, 现在轮到自己设计需求, 并分析需求的时候, 才知道上面写的每一个字都不是废话来的, 都是在脑子里转过八百六十圈才难产出来的(我比较笨)