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