首先理一下主要的功能模塊, 通過對功能關系的梳理, 整理出需要建的數據表:

1. 所有文章列表 --- post 表
2. 用戶發表文章 --- user 表, 與 post 表是"一對多"的關系
3. 用戶購買文章 --- order 表, 與 post 表是"一對一"的關系, user 表與 post 表是"一對多"的關系
   對於 user 表, 需要理解的是這裏既有文章的作者, 又有文章的購買者, 因為一個用戶登陸了, 不能因為身份的切換再切換賬號, 這裏需要在 user 表裏用類似於 type 的字段區分. 然後, 作為作者的身份, 一個用戶可以發布多篇文章, 所以與 post 表是簡單的"一對多", 但是, 作為購買者的身份, 一個用戶可以購買都篇文章, 而一片文章又可以同時被多個用戶購買, 所以形成了二者是"多對多"的關系, 顯然, 這裏我們需要一個中間表, 我們把其定義為 order 表. order 表的首要作用是作為中間表存在的, 但是我在設計表結構的時候, 會為其增加幾個冗余字段, 比如訂單號, 文章標題等等.
4. 訂單快照 --- order_items 表, 為了更好地記錄每筆訂單發生的時間, 價格等信息
5. 系列教程 --- series 表, 除了單片文章, 還會有系列教程, series 表與 post 表是"一對多"的關系.
6. 管理員表 --- admins 表
7. 支付信息表 --- pay_logs 表, 用於記錄與微信支付的相關信息
8. 留言表 --- comments 表, post 表與 comments 表是"一對多"的關系, user 表與 comments 表也是"一對多"的關系

以上是基於對建表的需求做的分析, 下一篇會具體實現上述數據表. 哈哈, 這裏我想吐槽一下我自己, 記得以前我跟著 laravel-china 上的項目教程學習的時候, 我也幾乎都是閃過這些關於表格的說明的, 第一是覺得自己沒有實操, 看著米有感覺, 二是覺得表述得都很通俗易懂, 這裏是最可以快件的部分~~~ 但是, 現在輪到自己設計需求, 並分析需求的時候, 才知道上面寫的每一個字都不是廢話來的, 都是在腦子裏轉過八百六十圈才難產出來的(我比較笨)

從零開始搭建一個知識付費平臺 - 需求分析