雖然關聯式資料庫的歷史已有數十年之久，多數人也很熟悉相關的SQL語法跟操作，但不管是效能、易用性、彈性及擴充性，關聯式資料庫都有值得商榷的地方。
每次跟使用者訪談需求後，開始設計資料庫時，往往要做第一正規化、第二正規化及第三正規化，因為我們要節省儲存空間，去除一些重複性，還有相依性的資料，但資料做完正規化後，其實跟當初訪談的內容，已經不夠實際了。
[ 下載 2020-21 CIO大調查報告，掌握最新企業IT導入趨勢 ]
所以日後要查詢儲存到資料庫的資料時，就得下一堆SQL指令，可能會關聯加入一大堆表格（Table），才可以找到我們要的資料。如果SQL語法下得不好，小則可能要等很久資料才會出來，大則可能會造成整個表格被鎖住（Lock），甚至連累到其他系統的運作。
因此，如果要重構HIS資料庫，我不會再選擇關聯式資料庫管理系統，會選NoSQL，因為NoSQL才是更趨近於真實的資料庫。
當前HIS資料庫面臨的問題
當HIS系統在查詢病歷資料時，會關聯很多表格，有時候本以為會以表格A的索引做關聯，但資料庫卻自做聰明，根據資料筆數來最佳化查詢索引，改用表格B的索引，使得查詢效率突然下降很多，若查詢的資料量太大時，還會造成表格非常忙碌擁塞，導致整個系統短暫的停擺。
為了避免這種情事發生，我們還要特別寫死程式強制指定索引。為了避免此事件發生，每周還要在固定的時間更新統計資料（Update Statistics）以達到最真實的資料統計筆數，避免資料庫誤判資料筆數而亂用索引鍵。
為了要加速HIS系統資料庫的效能，線上資料庫可能只能保存一定的年限的資料，否則一旦電腦當機後，資料復原（Recovery）的時間就會拖得太長。然而，資料如果累積到一定的量，就得做備份，每個月或每年都得進行資料維護，把累積的資料搬到另一個地方。所以問題就來了，如果醫師需要查詢比較早期的資料，寫程式的人可能就會很麻煩，程式得寫成到A主機抓三年前的資料，如果還要更早的資料，再到B主機去抓，於是資料不斷的封存，程式也不斷的改寫，也就是資料越來越多的時候，就要去抓更多不同的地方，長期下來就可能會造成很大的問題。
[CIO都在讀： 醫療業關鍵基礎設施資安進入落實階段 ]
許多醫院的關聯式資料庫也是個問題，例如原本是十個欄位的表格，因為需求而要再增加一個欄位時，如果這個表格太大，做資料結構異動時，資料庫就會先鎖住表格，而導致醫療系統作業停擺，或者是遇到醫療系統正在使用時，系統也會鎖住表格，就無法增加欄位。為了避免前述狀況發生，就只能利用臨床作業的離峰時期，以我們醫院來講，通常是淩晨四點到五點才能停機去增加欄位，也因此會增加不少的人力跟時間成本。
其實資料庫面臨到的主要問題，就是以前的資料空間因為不允許那麼大，所以資料都要精簡，就必須要去進行正規化作業。以關聯式資料庫來講，正規化就是去除重複性的資料，以避免更新異常或者去除功能的相依性。有正規化，也會有反正規化，就是每個表格都有一組常用的查詢屬性，雖然重複但就不用參照其他表去查詢，可以大幅提升效能。
就像程式前端操作畫面，讓使用者輸入真實的資料，但若要存到關聯式資料庫，就得將資料正規化後，才儲存到資料庫中。假設日後前端有人想要查詢這個資料，我們就要把已正規化資料，從資料庫中關聯很多表格，以反正規化的方式關聯起來，反反覆覆地做正規化與反正規化的動作。
然而一個HIS資料庫的關聯式表格，可能就會有成千上百個表格，要查詢一個病歷資料，可要關聯五、六個表格才找到要的資料，所以傳統資料庫的正規化，反而會讓資料不夠真實且複雜。
傳統資料庫無法滿足醫療資料型態
以前是因為儲存空間要斤斤計較，為了節省空間，才要將資料正規化，但現在儲存空間變得很便宜，已經不需要斤斤計較，所以整個儲存觀念就要改變。
事實上，關聯式資料庫的形態已經無法滿足現在的醫療資料型態。因為醫療資料型態非常多樣，如文字類型的資料就有檢查報告、出院病摘；數字類型的資料像檢驗報告、生理訊號；圖形型態的資料有心電圖、手繪圖；聲音型態的資料有心音、口述報告；靜態影像資料有X光、CT、MRI；還有動態影像資料如超音波、心導管、內視鏡等，如果要用關聯式資料庫來儲存這些資料，就可能會較辛苦了。
如醫師每次看完診後，就會把資料儲存在HIS資料庫，但醫院為了追求無紙化，還會把醫師看診的資料，透過他的醫事人員卡去做簽章，存到電子病歷資料庫（EMR）。但如果HIS資料庫是以表格的方式儲存資料，也就是前面講的正規化，而電子病歷資料庫卻是以文件（Document）的方式來儲存，這兩個資料庫等於是各自儲存，無法整合。以醫院作業來講，兩個資料庫不同步就會很麻煩，這也是很多醫院沒辦法整合資料庫所要面臨的問題。
微服務後HIS資料庫要重構
醫院如果想要推動微服務架構，資料庫可能要重構。這個過程我比喻為「乾坤大挪移」，也就是說把本來單體式主機寫在一起的程式做功能性重構，把本來屬於單體的服務架構，每一個功能變成一個服務，拆解成不同的微服務，如果服務能量不夠，就再開另外一個。
如醫院就會有一組一組的服務，包括護理、醫囑、藥局等多個實例，假設有一個服務檢測可以承受一百多人，結果卻來了兩百個人，工作量大到沒辦法執行時，就可以變成兩個服務，我稱之為「螞蟻雄兵」，就是說一個服務可以應付一百個人，三百個人就用三個服務去應對，如此一來，就可以確保整個系統的穩定性，不會因為工作量突然增加，伺服器就被衝垮。
這就是現在很多系統為什麼要從集中式變成分散式的原因。但問題來了，如果服務架構都拆開重構了，一千個人需要服務時，我就可以開十台伺服器來提供服務，但如果資料庫卻沒有跟著解決，這一千個人的資料都只能在一個集中式資料庫，日後的瓶頸就會出現在資料庫裡面。
[CIO都在讀： IT必須掌握的新核心能力 ]
程式既然都要重構，資料庫是不是要切割成「微資料庫」？但問題的根源則是太過於依賴關聯跟交易，很多東西我們必須要去做join，或者是view或者做transaction。如果要解決這些太過度依賴的關聯跟交易，首先要做的是垂直切割，也就是我們要設法依照不同的功能切割不同的表格，再將不同的表格可以獨立放到不同的資料庫。
另一種作法是水平切割，就是降低資料筆數，才能夠讓資料可以快速查詢，而且碰到當機時地復原時間不會太久。如何執行跨越服務之間的交易，以及讓多個使用者的資料做到實體隔離的多租戶設計，都是我們要面臨的挑戰。
但如果要用集中式資料庫來處理前述問題，就真的很困難。因為一旦要走微服務架構，就一定要把資料庫拆解，拆解成一個服務對應一個資料庫，讓服務歸服務，服務跟服務之間再去做資料交換，就可能要用分散式資料庫，才有辦法解決前述問題。
所以微服務既然屬於分散式架構，資料庫也必須要遵照分散式架構做改變，日後真的需要延伸時，就可以很方便的做到，這也是集中式和分散式資料庫的對照。
[ 加入 CIO Taiwan 官方LINE，與全球CIO同步獲取精華見解 ]
NoSQL的優勢
要做分散式資料庫，就不能不提NoSQL。NoSQL的意思是「Not Only SQL」，也就是不限定為「關聯式資料庫」的資料庫管理系統的統稱。在操作上，NoSQL並不支持SQL語法與SQL的邏輯。所以，NoSQL不使用關聯模型，且不需要固定的結構（Schema-free），假設現在有十個欄位，未來可能會新增五個時，可以很容易很輕鬆的去加欄位，即時自動加起來都沒有問題，可以是很真實的。
NoSQL的操作因為屬於分散式多資料中心，不需要用特定或者緩存層來儲存資料。NoSQL的架構非常靈活，可以輕鬆的去更改，不會造成停機或者中斷，要加幾個欄位時，不用停機或者服務中斷。諸如此類，這麼多的好處，讓我覺得未來的HIS資料庫，應該是屬於NoSQL，才是最佳的拍檔。
（口述／孫培然 彙整／CIO編輯室）
- [ 以NoSQL重構HIS資料庫(中) ]
- [ 以NoSQL重構HIS資料庫(下) ]
