本篇文章更新時間：2019/02/16
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
這個消息是看大神Blog來的。
雖然用開發者身份報了不用搶票的 COSCUP 2015 活動，但因為太忙沒做好功課就殺過去實在是比新手還新手XD
不過還好經驗就是
等風頭過了，就會有懶人包
的懶人吸收法(在此對願意分享的大大表示感恩阿)
回到主題
這是一件滿令人興奮的事，當存入資料庫中的資料可以提高相容性與複雜度的時候，開發上彈性就很大了。在此之前 JSON 這格式的資料僅是被當做 TEXT 型態寫入資料庫中放著，要去解釋這樣的資料還得先撈出來，透過程式去 parsing 後才可以，如今 PostgreSQL 9.4 版已經加入 JSON 型態的支援。
目前 MySQL 還沒有這樣的功能
下面使用情境，簡單舉例
如果學校要建立學生資料，一般建立的 SQL Schema 的時候就是要先分析好學生這個角色的屬性，所以資料表就會是
sid 學號(UNSIGNED INT)
name 姓名(CHAR)
gender 性別(INT)
birthday 生日(DATE)
一段時間或是在快速開發的過程中發現這些欄位不敷使用了，需要再多一些欄位，這時候就需要使用 ALTER 指令來插入新欄位，但這樣的操作除了是兩面的，要動資料庫也要動程式碼，不是很直覺。
這個例子中，通常經過分析後關鍵的屬性不會被遺漏，會發生這種事的可能都是後期追的加值服務所致，比方說 興趣 、 專長 這樣，此時若支援JSON資料型態的資料表就可以用個 其他 欄位來取代
sid 學號(UNSIGNED INT)
name 姓名(CHAR)
gender 性別(INT)
birthday 生日(DATE)
otherInfo 其他資訊(JSON)
OS: 甚至除了學號以外，其他全部欄位都使用一個student (JSON)來取代都可以。
這樣子程式在開發過程中對寫入欄位的彈性就出來了，當然彈性這回事都會反饋在管理上增加複雜度。
複雜度...恩(等實戰開發碰到了再來聊XD)
btw,
即將在8/26退伍，這一年在教育處服役的時候有看到一個大案子，跟中區縣市一同開發關於學籍管理的系統，這個系統雖有清大技術團隊在主導(採用MongoDB)，但是到基層的時候他們是很迷惑的，不了解該怎麼樣的架構才是適合用的系統，接手業務的老師一來不是專業二來還只是臨時的業務承辦人，時間又很急迫資料欄位又還沒這麼清楚，從往年的經驗來看，這一套花人民納稅錢出來的產物又會淪為一套只有包裝的工具。(各區都有這樣類似的管理系統)隨著資訊的進步，國家有些建設不能只有硬體上跟進，軟體層面也該有國家的等級，如果這樣的學籍管理系統能夠是全台灣等級，將會不只在作業上方便不少，也能夠做為研究用途，讓數據說話不正是一個科學的做法嗎？
相信這樣的未來應該不遠了。