3 回答

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

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