摘要:談?wù)勅绾卧O(shè)計(jì)評論表的表結(jié)構(gòu)前言打算使用打造一個(gè)博客的后臺,遇到了如何設(shè)計(jì)評論表的困惑,因?yàn)槿绻捎瞄_放評論的模式,就會導(dǎo)致評論的層層嵌套,使得管理和展示都變得非常復(fù)雜。
談?wù)刴ongodb如何設(shè)計(jì)評論表的表結(jié)構(gòu)
前言:
打算使用node+koa+mongodb打造一個(gè)博客的后臺,遇到了如何設(shè)計(jì)評論表的困惑,因?yàn)槿绻捎瞄_放評論的模式,就會導(dǎo)致評論的層層嵌套,使得管理和展示都變得非常復(fù)雜。通過各方探索和思考,我發(fā)現(xiàn)了一個(gè)非常不錯(cuò)的設(shè)計(jì)方法,在此分享給大家,希望可以對同樣困惑的人給與幫助。
說明:
1.我在設(shè)計(jì)的時(shí)候不考慮評論的評論的評論這種操作,我也是借鑒了sf這個(gè)網(wǎng)站的設(shè)計(jì),因?yàn)槿绻紤]到這層操作,這個(gè)表結(jié)構(gòu)的設(shè)計(jì)就會變的相當(dāng)復(fù)雜,畢竟不是群聊,而且該評論下的動態(tài)會推送給所有人,你們?nèi)绻胍涣骺梢灾苯釉谧畲蟮脑u論下評論,或者發(fā)私信,所以沒必要考慮到這一層。
2.這種設(shè)計(jì)是我個(gè)人的想法,初生牛犢,難免會有不成熟的地方,希望有不足的地方可以評論或者發(fā)私信告知我改正,方便我們學(xué)習(xí)成長。
評論表的表結(jié)構(gòu):
{ "_id" : ObjectId("597aa23add840cd4ce0681d1"), "comment_blog_id" : "blog id", "comment_user_id" : "A", "comment_content" : "A的評論", "create_time" : "2017-15-12 14:00", "comment_responses" : [ { "response_user_id" : "B", "response_user_phone" : "B的phone", "response_user_nickname" : "B的nickname", "response_content" : [ "這是B給A的評論(帶著索引index)", "這是B給A的評論(帶著索引index)", "這是B給A的評論(帶著索引index)" ], "create_time" : "2017-15-12 14:00", "get_reply" : [ "這是A給B的某一個(gè)評論的回復(fù)如果有就對應(yīng)插入index對應(yīng)的元素沒有就是空串", "A沒有回復(fù)B這一條就是空串", "A個(gè)神經(jīng)病跳著回復(fù)了這一條評論,這數(shù)組的第三個(gè)元素就是A回復(fù)的內(nèi)容" ] }, { "response_user_id" : "C", "response_user_phone" : "C的phone", "response_user_nickname" : "C的nickname", "response_content" : [ "這是C給A的評論(帶著索引index)", "這是C給A的評論(帶著索引index)", "這是C給A的評論(帶著索引index)" ], "create_time" : "2017-15-12 14:00", "get_reply" : [ "這是A給C的第index個(gè)評論的回復(fù)", "A沒有回復(fù)C這一條就是空串", "A個(gè)神經(jīng)病跳著回復(fù)了這一條評論,這數(shù)組的第三個(gè)元素就是A回復(fù)的內(nèi)容" ] } ] }
插入與展示的方法
1.A在B的第index條評論下回復(fù)了B,那么對應(yīng)的內(nèi)容就存放在get_reply[index]里面。
2.展示的時(shí)候先遍歷顯示A的評論
3.然后遍歷A里面的comment_responses數(shù)組。
4.接著遍歷comment_responses數(shù)組中的元素的response_content數(shù)組
5.以第一條為例,遍歷response_content數(shù)組顯示B給A的評論,然后檢查get_reply數(shù)組中的對應(yīng)索引的元素是不是空,空代表沒有回復(fù),不顯示,非空則跟著這條評論顯示回復(fù)。
6.以此類推即可完成顯示。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/19043.html
摘要:設(shè)計(jì)一個(gè)好的并非易事,本文先從設(shè)計(jì)時(shí)最容易犯的兩個(gè)錯(cuò)誤開始介紹,然后引出如何合理地設(shè)計(jì)。錯(cuò)誤以為設(shè)計(jì)的依據(jù)以為設(shè)計(jì)的依據(jù),往往是一個(gè)對應(yīng)一個(gè)子,的結(jié)構(gòu)同返回的數(shù)據(jù)結(jié)構(gòu)保持一致或接近一致。至此,的結(jié)構(gòu)設(shè)計(jì)完成。 Redux是一個(gè)非常流行的狀態(tài)管理解決方案,Redux應(yīng)用執(zhí)行過程中的任何一個(gè)時(shí)刻,都是一個(gè)狀態(tài)的反映。可以說,State 驅(qū)動了Redux邏輯的運(yùn)轉(zhuǎn)。設(shè)計(jì)一個(gè)好的State并非...
摘要:前言在使用加載數(shù)據(jù)數(shù)據(jù)庫常見的優(yōu)化操作后端掘金一索引將放第一位,不用說,這種優(yōu)化方式我們一直都在悄悄使用,那便是主鍵索引。 Redis 內(nèi)存壓縮實(shí)戰(zhàn) - 后端 - 掘金在討論Redis內(nèi)存壓縮的時(shí)候,我們需要了解一下幾個(gè)Redis的相關(guān)知識。 壓縮列表 ziplist Redis的ziplist是用一段連續(xù)的內(nèi)存來存儲列表數(shù)據(jù)的一個(gè)數(shù)據(jù)結(jié)構(gòu),它的結(jié)構(gòu)示例如下圖 zlbytes: 記錄整...
閱讀 3062·2023-04-26 00:40
閱讀 2401·2021-09-27 13:47
閱讀 4254·2021-09-07 10:22
閱讀 2971·2021-09-06 15:02
閱讀 3316·2021-09-04 16:45
閱讀 2503·2021-08-11 10:23
閱讀 3607·2021-07-26 23:38
閱讀 2907·2019-08-30 15:54