SQL Server
一般來說，在現有的Table裡面增加新的欄位是不可避免的事
但Shcema的更動，很有可能會影響到你現有生產環境的程式碼，不過也是得看程式碼怎麼寫
若是你今天是指定欄位Insert的話，你新增欄位絕對不會有什麼問題
Insert into Table (ID, column1, column2)
select 1, 'col1', 'col2'
假若你今天沒有指定欄位 (在早期沒有那麼熟的情況，有些人會這樣寫，不要懷疑就是有人會這麼做，那個人就是我 )
Insert into Table
select 1, 'col1', 'col2'
科技來自於惰性，當你的Table欄位夠多夠長的時候(30個欄位以上)，也許你一不小心就會幹出這種事
這時候你新增了column3的時候，你就會發現程式爆炸了!!!
所以指定欄位是等同於是買保險
當然你也會說，現在都用Entity Framework 5.0, 6.0了，哪會有人犯這種錯
的確，Entity Framework也是用指定欄位的方式來做 Insert table的動作，所以Entity Framework很貼心的幫我們避開了這個問題
但還沒有Entity Framework的時候，遠古程式幾乎可以看到這樣的寫法
好在Entity Framework出現了，除了避開新增欄位的問題，也同時避免SQL Injection的問題
真是摸蛤兼洗褲啊
不過今天要探討的另一個問題是，若是我需要上線一個新功能
這個功能包含了新增欄位之外，還有順便將其他欄位順序做調整
在生產環境不能停下來的情況下，我們需要怎麼上線程式？
生產環境若是指定欄位塞，由於我們並不清楚SQL Server究竟怎麼運作
有沒有可能在調整欄位順序的同時造成資料誤塞到不同的位置呢？
真是越想越可怕，所以只好手動做個簡單的測試來證明SQL Server的清白
我在測試環境開了一個Table，欄位有Seq(Key), Column1, Column2, Column3
首先我先用bulk insert 先塞了20萬筆模擬正式環境的量
再來是開幾支Thread去做塞資料的動作
在這同時，我去變更Table Shema，變動後的欄位為 Column4, Seq(Key), Column1, Column11,Column2, Column22,Column3
你可以發現column的順序是全然不同了
若是SQL Server是以Column的位置來塞的話，勢必會出現塞錯欄位的問題
在Save shema change的時候可以發現非常的緩慢，雖然僅僅只有20萬筆資料而已，畢竟同時也有幾支Thread正在存取塞資料，會慢也是正常的
好不容易終於成功了
結果當然是相當讓人滿意，存取的順序都是相當正常的，終於證明了SQL Server的強大
有了這項證明，生產環境的Table Schema當然就可以很心安地去直接做更改與調整了
