最近需要搭建一個隨時可以用的CMS系統(tǒng),但是不想用別人開發(fā)的系統(tǒng)茬暇,于是自己著手設計了一波文章+評論的數(shù)據(jù)庫霹期。
這篇文章主要列一下文章和圖集的概要。
!!!! 所有數(shù)據(jù)快压,最好不要設置外鍵
然后經(jīng)過細細揣摩后圆仔,對這些概要進行MySQL數(shù)據(jù)表設計(緩存如何存就不說了,每個業(yè)務設計不一樣)蔫劣,如圖:
這里只對幾張表進行字段闡述坪郭,因為其他都可以理解清楚的
分類表
字段 | 類型(長度) | 釋義 |
---|---|---|
分類ID | int(11) | 主鍵,也可以使用隨機字符串脉幢,隨意 |
分類名稱 | varchar(8) | 分類2-4個漢字 |
排序 | int(11) | 用于前端顯示排序 |
創(chuàng)建時間 | int(11) | 時間戳 |
父級分類ID | int(11) | 默認0歪沃,關聯(lián)本表的分類ID ,主要做二級分類用 |
刪除時間 | int(11) | 時間戳嫌松,用于數(shù)據(jù)冗余沪曙,以后做分析 |
主體表
字段 | 類型(長度) | 釋義 |
---|---|---|
文章ID | varchar(50) | 主鍵,使用隨機字符串萎羔,目前采用 md5(作者賬號+隨機數(shù)) 生成 |
標題 | varchar(100) | 標題簡要明了液走,100都多了 |
作者 | varchar(20) | 這里主要存儲 用戶系統(tǒng) 的賬號ID |
類型 | tinyint(1) | 文章類型 ,1圖集贾陷,0普通文章 |
封面圖類型 | tinyint(1) | 默認0無圖缘眶,1單圖,2三圖髓废,3自定義 |
定時發(fā)布時間 | int(11) | 時間戳巷懈,在前端展示的時候,定時發(fā)布時間應覆蓋實際發(fā)布時間 |
置頂時間 | int(11) | 時間戳慌洪,默認最新置頂?shù)脑谧钌厦?/td> |
通過審核時間 | int(11) | 時間戳顶燕,通過審核后更新該字段并異步添加一條審核記錄到審核表 |
上架時間 | int(11) | 時間戳,用戶可自行上下架蒋譬,上架需審核割岛,下架后重新上架也需要審核。 |
發(fā)布時間 | int(11) | 時間戳犯助,用戶真實發(fā)布時間 |
刪除時間 | int(11) | 時間戳癣漆,用于數(shù)據(jù)冗余,以后做分析 |
分類主體關系表
字段 | 類型(長度) | 釋義 |
---|---|---|
分類ID | varchar(50) | 分類表中的分類ID |
文章ID | varchar(50) | 文章表中的文章ID |
創(chuàng)建時間 | int(11) | 時間戳 |
更新時間 | int(11) | 時間戳剂买,這個字段至關重要惠爽,當文章有置頂和定時發(fā)布的時候癌蓖,這個字段應該與文章中的置頂或定時時間同步,方能保證根據(jù)分類獲取列表 時候婚肆,可以減小時間排序的誤差 |
是否生效 | tinyint(1) | 可選1和0租副,主要用于文章下架后或待審核前,文章不應該出現(xiàn)在分類下较性;以此字段來過濾分類下的文章ID |
刪除時間 | int(11) | 時間戳用僧,用于數(shù)據(jù)冗余,以后做分析 |
這些表設計來的作用是什么呢赞咙,我覺得還是舉例幾個說明比較好(復雜數(shù)據(jù)都是做過緩存的):
0.1 獲取分類列表(僅限二級)
獲取數(shù)據(jù)時候责循,進行自關聯(lián)查詢,可以獲取到一級和二級的分類列表
0.2 發(fā)布圖集
提交數(shù)據(jù)后攀操,對數(shù)據(jù)拆分后進行異步存儲院仿,分別存儲到
文章主體表
和圖集內容表
... ,如果做了緩存速和,可以先直接存儲到緩存歹垫,然后異步提交任務,由任務執(zhí)行者來執(zhí)行DB操作(沒做過線上測試颠放,目前新增數(shù)據(jù)是采用直接操作DB)排惨,可以減少響應時間。
0.3 獲取圖集詳情
在查詢時候默認查詢的是緩存慈迈,如果要查詢DB若贮,則先查主體表,再查圖集內容表
0.4 刪除圖集
可以直接僅更改
主體表
中文章和分類關系表
的刪除時間痒留,然后推一個異步任務去更新封面、內容表等其他表蠢沿,因為只要更新了主體表
和分類關系表
伸头,就沒有文章入口了,其他的自然也查不出來了舷蟀,把費時的操作拿給任務去做
目前這個數(shù)據(jù)表的結構配上緩存恤磷,還沒發(fā)現(xiàn)大問題,希望指教