最近整理出一些資料庫欄位長度更改，需要注意的事項，感覺中文資料不多(問GPT搞不好還比較快)，就來補一篇筆記上來，如果有其他建議或是參考資料(當然不限語種)，非常歡迎提出一起擴展我們的知識~

1. 資料庫：

   • 相關外鍵，需一並調整(調整則重第一步重新開始)
   • 效能/空間，資料長度加大會不會影響資料查詢的效能?占用空間?
   • 索引，欄位如果是索引需要重建，重新評估這個欄位是否適合當索引(如讀寫速率)
   • ERD model，需要跟著調整
   • Stored Procedure，View，一樣檢查是否有用到該欄位，涉及的邏輯是否有衝突
   • 現有資料，這個更動對於現有資料是否都可以符合
   • 資料型態，如果改的不只是長度，例如從char轉varchar,可能有意料之外的結果(參考資料)
   • 執行時間，一些語法調整資料庫欄位可能會鎖表，資料量大，經常有流量的表可能無法接受這段lock的時間需要注意(參考資料)

2. 後端：

   • 從Repository層往前檢查，後端程式碼有撈取到該欄位的相關變數，最後被引用到哪裡去，要寫入欄位的資料來源是否可接受這個長度
   • 連結的變數有沒有長度限制?
   • 連結的變數有沒有被間接套用到其他資料庫欄位?注意那個欄位的長度，是不是連帶影響要調整其他欄位
   • 資料庫對應的model需要重新產生或調整(如EntityFramework 產生的cs檔，.edmx檔)

3. 外部系統(通知各相關單位或團隊)：

   • 資料輸出，確認欄位資料串接到的外部系統(例如API串接)是不是可以接受這筆資料長度限制的調整
   • 欄位輸入，確認欄位的資料來源可以在這個長度限制內

4. 畫面：

   • UI，檢查欄位資料最後呈現的位置會不會破圖或造成跑版，RWD需要重新確認一次

5. 檢查部屬流程：

   • 先改Code還是先改資料庫?
   • 是不是需要停機更新?
   • CI/CD或單元測試是否有用到該欄位，長度變更是否影響功能執行