將JSON轉換爲SQL的最佳體系結構？

Question

我只是想知道如果任何人有任何想法將JSON文檔數據庫結構轉換爲SQL。它需要完成數據集成/倉儲。

JSON字段相對靜態，但是新的「字段」可以每隔2-4周就會出現一次。

由於這種性質，並轉換爲SQL ---我在想...解析所有的靜態字段到SQL字段。幸運的是，'動態'字段是JSON文檔的一部分。

我的想法是簡單地將可以容納50,100個字段的「動態字段部分」轉移到另一個SQL字段中，這些字段可以緩存更改。

這樣，無論JSON字段如何變化，至少ETL過程都是相對靜態的。

然後，第二層，或者「視圖」基本上可以將這個巨大的列解析爲它的單獨字段。 IE的巨柱可能會說「顏色：紅色;狀態：開放;城市：羅馬」......並且一系列字符串函數將解析這些以填充顏色，狀態和城市字段，也許在視圖中。

我不確定這是不是瘋狂的想法。另一種選擇是在JSON文檔中遇到MySQL時執行MySQL語句（添加列），但這是它自己的一套問題。

任何人都有這個想法？

並且說數據庫只被添加到，從未更新過。在這種情況下，'解析'只需要每行完成一次。一個觀點仍然是最好的選擇？或者完全是另一張桌子？

Answer 1

簡單策略：從JSON中解析出已修復且您知道的字段。把這些放在SQL表中。

您無法識別的字段將它們保留爲JSON。如果數據庫支持JSON類型，那就放在那裏。否則將其存儲在大字符串字段中。

不要開始將JSON解析爲匿名字段，尤其是當字段每週（或更多）更改時。現在大多數數據庫在某種程度上都支持JSON，所以在查詢數據時可以使用數據庫引擎進行解析。

Answer 2

這聽起來像你有一個「靜態」字段的句柄。你有沒有考慮過在「動態」字段中使用標記系統？也許是一個存儲值的表，一個主標記列表的外鍵（包含值類型定義（如字符串，int等）的所有可用「靜態」字段的列表）以及與字段值相關聯的實體的外鍵用？您當然必須爲已知的主標籤維護一個ETL過程，但這似乎簡化了一些事情。當添加新標籤時，您可以簡單地引入一些（希望）經過測試的SQL事務，將新標籤添加到您的系統中，並將其與您的應用程序一起版本化。我已經說了所有這些，我可能會進一步備份並做一些更多的設計工作，並提出一個策略，以便在應用程序層保持一致性，以支持在持久層執行此操作。 DDD +域事件，生產者/消費者模型，發佈/訂閱，演員語義或其他一些策略，可以將問題進一步解決。這聽起來像大多數這可能被綁定到一些維護屏幕，如果你願意做一些重新設計和重新定義你的一些業務對象/實體，在應用層保持一致。