關聯式資料庫有所謂的資料庫正規化，是幫助資料庫設計建置的原理和技術，減少數據冗餘和增進數據一致性(適度的正規化避免所有資料往同TABLE塞)
但如果資料來源是API，給的資料格式是JSON，那有沒有甚麼好的參考依據，心法或心得? (FOR 關聯式資料庫，不會使用NoSQL資料庫)
案例:有2個API，A API和B API(還會有其他資料但先簡化一點)
A API提供學校部類型(日間夜間進修碩士博士...)
B API提供部下的系所資料(資工資管會計統計化學...)
B的API Request需要提供A API的一個結果數值當參數(日間部的所有系所、進修部的所有系所)
這種模式下看起來好像可以A、B API拆不同TABLE，但如果這樣B API資料TABLE又通常需要A API的TABLE資料，這樣使用又每次都要JOIN(或寫成VIEW)
如果不拆TABLE，又好像沒什麼壞處(探討案例的API資料不會無限增長，而是類似上述舉例是有大約固定資料量的)
已邀請的邦友 {{ invite_list.length }}/5
先針對你回應的部份 "但公司畢竟不是走在最前面" 那我會建議你 "辛苦一點" 建構好完整個 "關聯式資料庫" 的處理，其他同仁如果不了解一些創新的技術或是公司業務並不需要有多先進的創新技術，那還是保持原有的技術就好，不要太創新!! 因為付薪資給你的是公司，太創新並不是好方法而是大家都同意了才來做。
我做過一個專案，透過某合作廠商將 API JSON 數據讀進來，並在 5~10 秒內將讀到的數據來進行換算(MSSQL 排程+SP)是否有達到 警戒值 當達到警戒值就透過程式發送簡訊請人來處理。
這專案所讀進來的 JSON 都有特定 ID ，讀進來後我將 JSON 用 TSQL 的功能來拆解資料並用 Table 來記錄，每一筆記錄都有 ID 是那一個地方的設備，設備達到設定值的話就進行後續的處理。我這些的處理都是透過 MSSQL SP 來解決掉，導出相關的資料也是透過 SP 將其資料來組合好導出 JSON 內容，程式對資料的處理可以少很多。
會寫 SP 總覺得 VIEW 是沒有用的功能，透過 SP 可以執行 exesql out json 來做資料的交換與處理，當然你文件與註解要寫的好，SP 內的 TSQL Script 要排序好，下一個人接手的人會感謝你
不拆 Table 當然是不建議啦，不為什麼而是公司內容系統都是用 關聯式資料庫-資料庫正規化 的話那就是以原本的方式來做
關聯式資料庫主要就是在處理結構化的資料，JOIN 的部分是不用擔心效能太差，但也記得在做資料正規化的時候不需要過度正規化。
另外如果你不想寫把每個 JSON 中的資料都拆成一個欄位，或是 JSON 吐回來的資料部會固定的化，是可以直接建立一張資料表，然後開一個欄位，欄位型態選擇 JSON，就可以直接把所有 JSON 型態的資料直接寫進指定欄位裡面，相關的資料可以問 GPT 或 Google，"如何寫入 MySQL JSON 欄位資料" 等等。
至於 JSON 欄位的資料查詢效率我就不太清楚了，是可以查沒錯，但效率的部分如果有大大想補充的話歡迎指教。
針對這種 JSON 格式的資料型態的話，個人這邊是建議直接使用 Mongo，查詢的速度也快，也夠彈性，但還是依開發需求而定。
這個問題沒有標準答案，
我認為只要開發團隊取得共識，然後留下足夠的文件就好
問十個人可能有十個不同的答案
iThome鐵人賽
看影片追技術