Spring Data Jpa 自動化的選擇 - Code First 科技新知

Spring Data Jpa 自動化的選擇 - Code First

Code First vs Database First

在早期SQL資料庫盛行的年代，在設計要使用資料庫儲存資料時，很經常遇到一個策略選擇的問題*Code First* vs *Database First*

這兩個策略的差異可能越來越講不清，筆者也找了一些現時網路上的講法。

Code First: 先從寫程式的角度出發，設計數據模型，再使用工具把你程式碼中的數據模型類(Class)，生成一個對應用SQL資料庫的表(Table)，自動編做好對應的數據結構(Schema)。這樣你在設計時，以程式設計為主導，方便熟悉程式的人使用。這常見於第一手開發設計，因為資料都是第一次收集和儲存，考慮收集程式的運作最為實際。

Database First: 先從SQL資料庫的儲存、取用資料的方式出發，先用SQL成生Table及Schema，再轉變成為程式碼中的數據模型。這樣的資料庫在日後作分析用途時，比較簡單易懂，方便使用熟悉SQL的人去使用。這也常見於二次開發程式，因為這樣可以確保不會錯誤地破壞原有資料庫。

那麼筆者為何講這兩個差異越來越講不清？那是因為現在的資料庫不能單純地只考慮初次或二次開發問題，而是需要考慮多個系統協調運行的問題。

多系統共享協定 - Database First

因為隨著資料系統發展，有些資料會作為數據源出現或用作共享媒界，如果一定要對設計策略作分類，在多系統協調運作下，這些應該叫使Database First。不論它們是SQL還是NoSQL資料庫，我們的程式碼都要為這個預先定義好的數據結構作出妥協。不論使用工具，還是人為分析，都要把共享的數據結構轉換成自己程式中的數據模型。

即使不是多系統協調運作，有時候因為要移植系統，但同時又要令兩個系統版本相容。新系統也是被逼使用Database First的方式設計。

自動化考量 - Code First

前述我們講到，很多時候我們也是從Database First的方式思考。不過筆者就這個Database First，也弄到滿身傷痕。

首先，拋開工具轉換的誤差，我們人為的把共享數據轉化為數據模型，共享數據有時會有一些先天的缺陷，例如: 資料沒有設計Primay Key (主鍵，唯一鍵)、日期時間的定義不明確等。面對一些意義不明的數據來源，要整合確實很要命。而且二次開發中，不可能100%重用原有的資料庫結構，很多時都會加入新的欄位或更多表格去計數。一旦加入新欄位，在團隊多人開發中，那麼使用唯一的共享開發環境，就變很易有程式碼上的衝突。

若需要多人開發，各人有一個Code First的開發用資料庫，是很必要的。這也可以在系統正式升級前，對比開發中資料庫及舊資料庫的結構，觀看它們之間的差異，評估升級的風險。

也許Code First並不是重點，重點是可以隨時建立一個測試用的資料庫，這才方便合作開發。自動化的地方，不單只限於數據結構，範例資料也該是如此。如果有維繫一個初始範例資料，可以在有需要時自動生成，對於多變的環境一定有很幫助。

現時，筆者基本上都會人為檢視資料庫，人工對照編寫程式中的資料結構(即是人工的Database First)，並確保那時程式再次經自動化生成的測試用資料庫，並沒有失真(即是Code First)。至於範例資料，初期筆者也只使用SQL生成，但後期因為資料結構開始複雜，筆者也暫暫使用程式碼生成，雖然工作量會多了，但對於資料庫升級、品牌更換，這是很有效的手段，程式碼升級測試也更順暢，絕比SQL生成更易維護。