如何快速建立業務模型並抽象化以及在數據建模和性能方面需要注意的事項


首先聲明,本人所有博客均為原創,謝絕轉載!

在我們的工作中,需求的具體實現邏輯往往是不明確的,一般都是老板或者產品甩過來一個頁面或者要求,剩下的就要靠我們自己去思考了,而建立業務模型,往往就是開發中最難也是最燒腦的一步.很多人可能想許久都不知道一個業務該怎么實現,或者是先想清楚了,但做着做着就發現之前的邏輯是錯的,又只好重新改.

但是,這個過程對我來說則並不是很困難,因為我掌握了較為正確的數據建模的思考方式,下面我就以最近做過的評論模塊和權限模塊兩個案例來說下怎么樣才是我認為合理的業務建模的思考方式.

首先說下評論模塊(在我的博客 https://www.cnblogs.com/yangfeiORfeiyang/p/9184412.html 里有評論模塊的展示):

關於評論模塊,可能不像各位都有需求文檔之類的非常詳細的敘述業務需求的東西,當時我做這個的時候我們領導就甩給了我一個微博評論的截圖,然后讓我按照上面做(沒有聽錯,就只有一張截圖,甚至連前端都是我自己寫的)

類似於這張

當然要注意的是,新浪微博這個其實是典型的一級回復,而我當時要做的則是要有二級回復的,也就是一張報表底下有一個評論區,然后A評論了,那么此時他是一級評論,而如果B評論了A,那么此時他則是二級回復,當然此時如果有個C,那么他也可以去評論B,但是此時在頁面顯示上不會再出現一個獨立評論區,而是會在A的評論區下面出現C回復B:

oK,拿到需求了,那么此時我們要干的第一件事情是什么呢?分析業務,數據庫建模(也就是建表設計字段)

首先我們來分析業務:

既然是評論,那么我們首先需要將評論這個對象模型化,我們建立一個表remark,而評論有哪些屬性(字段)呢?

1:一條評論是人發出的,那么肯定需要跟user表進行關聯,加一個字段userId

2:人發出的東西是什么呢?是字符串,而且我們需要確保每條評論不能太大,要不然很容易出現刷屏的現象,當然,這個我們會在前端和服務器端進行把控攔截和驗證但是數據庫中也同樣要保證不會出現這個問題,所以我們不能用text或者blob這種沒有長度限制的類型,而應該設置定量長度並且數據空間可伸縮的varchar

3:我們還需要知道這個評論什么時候發的,所以需要加上字段createTime

4:評論是可回復的,並且有一級和二級之分,而且還有回復人,那么此時我們需要加上一級回復id,oneReplyId和二級回復人id,twoReplyId

5.因為評論有時候可能涉及到和諧因素,所以我們需要保留,哪怕被刪了,也不能物理刪除,只能邏輯刪除,所以添加字段flag;

6.考慮到報表評論功能的專業性,需要添加一個審核字段,留着后期功能拓展使用,添加字段 isCheck;

Ok,差不多這樣就能滿足我們的需求了,大家這里應該可以看到,其實我完全可以再建立三個冗余字段userName,oneReplyName和twoReplyName,這樣查數據的時候就很輕松了,如果你這樣想,那就死定了,因為大家注意一下,userName也就是用戶昵稱是一個可更改的數據,而如果我加了這三個字段,那么為了保證數據同步,我就必須要在

用戶更改昵稱的地方,將我現在的評論里所以與其關聯的評論的昵稱也全部修改,這樣會導致,這個人如果發了一千條評論,或者被一千個人評論過或者自己評論的加別人評論的超過一千條,那么我只是改一個用戶昵稱就需要改掉一千條數據!!!關於怎么建立良好可維護的冗余字段我后面會單獨講.還有,使用好合理的緩存,就不必擔心因為關聯而需要產生的多條sql語句

現在評論已經完事了,那么我們再來看看這個點贊功能,首先,點贊肯定是一個單獨的模型(表),因為一個用戶可以對多條評論點贊,一條評論也可以被多個用戶點,所此時這個點贊表其實就是用戶和評論的一個多對多關系中間表.(請注意,如果沒有點贊功能,那么用戶和評論之間是一對多的關系)

理清了關系,那么我們再來看下如何建立:

1.首先建立dianzan這個表模型.

2:因為點贊是由用戶發出的,我們必須要知道是哪個用戶,所以建立一個字段userId

3:因為用戶是對評論進行點贊的,所以需要建立一個字段remarkId

但並不是建好表插入數據就夠了,大家想一下,點贊和取消贊,這兩個功能其實是非常頻繁的,關鍵是他還不是非常關鍵的業務數據,如果因此就浪費掉我們數據庫寶貴的TPS實在是可惜,所以我們需要在項目啟動的時候就將點贊的數據全部加載到緩存中,之后對於點贊功能的操作全部都要在緩存進行,如果是Redis的話使用hash數據結構即可,如果是MangoDb或者ehcache這種

key value的單一緩存中間件和插件的話,將KEY設置為用戶ID加評論ID,Value設置為Map即可,因為用戶ID加評論ID是能保證每個點贊的唯一性的,所以散列結構的時間復雜度妥妥的O(1).還有要注意:點贊功能只有添加和刪除,沒有修改這種事情.最后關於點贊緩存的更新問題,在晚上的時候用定時器批量更新即可.

好了,到這里基本上評論的數據建模就完成了,關於權限那塊,因為要講和分析的東西太多,所以今天沒時間講完了,留着下次吧!最近在玩前端,各位如果有認識的比較厲害的前端小姐姐,可以介紹我認識下哈.當然,真的只是討論問題.

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM