3 回答

TA貢獻(xiàn)1842條經(jīng)驗(yàn) 獲得超22個(gè)贊
像大多數(shù)事情一樣,“取決于”。將數(shù)據(jù)存儲(chǔ)在列或JSON中本身并沒(méi)有錯(cuò),對(duì)錯(cuò),好壞。這取決于您以后需要做什么。您訪問(wèn)該數(shù)據(jù)的預(yù)期方式是什么?您是否需要交叉引用其他數(shù)據(jù)?
其他人已經(jīng)很好地回答了技術(shù)上的權(quán)衡。
沒(méi)有多少人討論過(guò)您的應(yīng)用程序和功能會(huì)隨著時(shí)間的推移發(fā)展以及這種數(shù)據(jù)存儲(chǔ)決策如何影響您的團(tuán)隊(duì)。
因?yàn)槭褂肑SON的一種誘惑是避免遷移模式,所以如果團(tuán)隊(duì)沒(méi)有紀(jì)律,那么很容易將另一個(gè)鍵/值對(duì)粘貼到JSON字段中。沒(méi)有它的遷移,沒(méi)有人記得它的用途。沒(méi)有驗(yàn)證。
我的團(tuán)隊(duì)在PostgreSQL的傳統(tǒng)列中使用了JSON,一開(kāi)始這是自切面包以來(lái)最好的方法。JSON具有強(qiáng)大的吸引力,直到有一天,我們才意識(shí)到靈活性是有代價(jià)的,這突然成為一個(gè)真正的痛點(diǎn)。有時(shí),這一點(diǎn)會(huì)迅速上升,然后變得很難更改,因?yàn)槲覀冊(cè)诖嗽O(shè)計(jì)決策的基礎(chǔ)上建立了許多其他功能。
隨著時(shí)間的推移,添加新功能以及將數(shù)據(jù)存儲(chǔ)在JSON中導(dǎo)致的查詢看起來(lái)比如果我們堅(jiān)持傳統(tǒng)列可能添加的查詢更為復(fù)雜。因此,我們開(kāi)始將某些關(guān)鍵值返回到列中,以便我們可以進(jìn)行聯(lián)接并在值之間進(jìn)行比較。餿主意?,F(xiàn)在我們有了重復(fù)。新的開(kāi)發(fā)人員會(huì)加入并感到困惑嗎?我應(yīng)該存回哪個(gè)值?是JSON還是列?
JSON字段變成了諸如此類的小片段。沒(méi)有數(shù)據(jù)庫(kù)級(jí)別的數(shù)據(jù)驗(yàn)證,文檔之間沒(méi)有一致性或完整性。這將所有責(zé)任推到了應(yīng)用程序中,而不是從傳統(tǒng)列中進(jìn)行困難的類型和約束檢查。
回顧過(guò)去,JSON使我們能夠非常快速地進(jìn)行迭代并獲得成功。太棒了。但是,在我們達(dá)到一定的團(tuán)隊(duì)規(guī)模之后,它的靈活性也使我們陷入了沉重的技術(shù)負(fù)擔(dān)之中,從而減慢了后續(xù)功能開(kāi)發(fā)的進(jìn)度。請(qǐng)謹(jǐn)慎使用。
認(rèn)真思考一下數(shù)據(jù)的本質(zhì)。這是您應(yīng)用程序的基礎(chǔ)。隨著時(shí)間的推移將如何使用數(shù)據(jù)。并有可能改變嗎?

TA貢獻(xiàn)1816條經(jīng)驗(yàn) 獲得超4個(gè)贊
只是把它扔在那里,但是WordPress具有這種東西的結(jié)構(gòu)(至少WordPress是我觀察到的第一個(gè)地方,它可能起源于其他地方)。
它允許無(wú)限制的鍵,并且比使用JSON blob更快地進(jìn)行搜索,但不如某些NoSQL解決方案快。
uid | meta_key | meta_val
----------------------------------
1 name Frank
1 age 12
2 name Jeremiah
3 fav_food pizza
.................
編輯
用于存儲(chǔ)歷史記錄/多個(gè)鍵
uid | meta_id | meta_key | meta_val
----------------------------------------------------
1 1 name Frank
1 2 name John
1 3 age 12
2 4 name Jeremiah
3 5 fav_food pizza
.................
并通過(guò)類似這樣的查詢:
select meta_val from `table` where meta_key = 'name' and uid = 1 order by meta_id desc
添加回答
舉報(bào)