軟體主廚的程式料理廚房

這個標題聽起來像是廢話，我們有一個集合，怎麼把它變成 Table？　啊不就 INSERT INTO 就好了？我要介紹的不是只有 INSERT INTO 而已，我們在寫 SQL 的時候，偶爾會遇到一種場景，我們手上有一個集合，這個集合的值是固定的，比如說年份 2011 ~ 2020、月份 1 ~ 12、...等，這個集合我們會拿去跟現有的資料做 JOIN，進行一些統計運算，我們把這個集合變成 Table，在操作上就會比較方便一點，我就我所知的四種方法來跟大家分享。

如果我們接手維護一個資料庫，裡面的 Table、View、Stored Procedure、Function、Trigger 相依鏈錯綜複雜，想要定位發生問題的區塊，搞得像盜墓一樣，這天我無意間發現 SSMS（SQL Server Management Studio）有一個「檢視相依性」的功能，有助我們來釐清資料庫物件的相依鏈。

在 SSMS 中任何一個資料表按右鍵，使用「編寫資料表的指令碼為」的功能來產生建立資料表的指令碼，預設是不會產生索引的指令碼，這其實是一個小問題，但不是常常會需要去設定它，久了就忘記了，這邊就做個記錄，以便日後回想。

在過往的需求中，難免會有那種需要按照順序產生或處理資料的時候，我個人常用的解法是替資料照著順序給一個可排序的標記，這就需要一個按照順序產生識別碼的機制，如果在同一個應用程式內還好處理，要是跨應用程式、跨機器的話，產生識別碼的演算法就要好好想想，現成的話 SQL Server 就有一個 SEQUENCE 功能可以用。

SQL Server 的資料型別中有一個 float，這個 float 在 C# 對應的應該是 double，而 C# 的 float 對應的 SQL Server 資料型別應該是 real，那如果將 real 對應成 C# 的 double 會發生什麼事？　答案是小數點的精準度會跑掉。

我個人認為 SQL Server 預設拿主鍵（Primary Key）來當叢集索引（Clustered Index）欄位這件事情，應該要被重新考慮，以目的來講，主鍵與叢集索引的關係其實並不大，主鍵的目的是確保資料是唯一且正確的，而叢集索引的目的是提升查詢效率，所以在這點上，我覺得在資料表一個開始設計的時候，預設是分開考量的會比較恰當。

用過 Dapper 的朋友應該對它是愛不釋手，最近在一個對效能敏感的系統上 tune SQL 查詢語句時，發現到 SQL 參數型別的不同及使不使用 SQL 參數，對執行計劃的選擇影響甚大，相同的查詢條件及結果，只因改了參數的型別，執行計劃就跟著改變，查詢成本也跟著拉高。

在 SQL Server 可商用的版本中，Express 及 Web 版本是唯二沒有完整 Replication 的版本，但是一個免費、一個便宜，對於老闆來講這是一個可以節省成本的點，如果真的有 Replication 的需求，除了升級之外，我們還可以寫點程式自己土砲。

ROW_NUMBER() 是在 2008 的時候出現的，自從它出現之後，我做分頁查詢就都是用它來做，從 SQL Server 2012 開始出現了 OFFSET / FETCH，它類似於 C# 中的 Skip() / Take() 這種跳過幾筆取幾筆的方式，知道之後就都改用 OFFSET / FETCH 來做分頁查詢。

之前的報表，老闆覺得還不夠，他還想再看到一些數據，於是就開需求了「Johnny 啊，我想再看到每個分店每月銷售額跟他們最好及最差的那一個月相比，看看差了多少百分比。」，當然沒問題，付錢就行。