軟體主廚的程式料理廚房

我個人認為 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 啊，我想再看到每個分店每月銷售額跟他們最好及最差的那一個月相比，看看差了多少百分比。」，當然沒問題，付錢就行。

上一篇文章提到依日期彙總結果，這時候老闆又開需求了「Johnny 啊，能不能幫我多加一個欄位，讓我看到每個分店當月銷售額與上個月銷售額相比的成長百分比？」，這個需求也很常出現在我的程式設計生涯當中，我們來看看在 SQL Server 中怎麼來實現。

假定老闆提了一個需求，他想要看每個分店每天的銷售額，如果當天沒有銷售額的分店則銷售額顯示為 0，這個需求我們從訂單資料庫裡面彙總出來就可以呈現了，但是它有一個點在於萬一某個分店在某天沒有訂單，那麼該分店在訂單資料庫是沒有資料的，則該分店的該天銷售額必須標為 0，類似這樣的需求經常在我的程式設計生涯中出現。

無論是業務需求或是 IT 需求的關係，依據不同需要將資料庫分放在不同伺服器的情形很多見，要進行跨資料庫伺服器交易我們可以啟用 MSDTC 服務來達成，我就在想能不能不去動伺服器的設定，在應用程式端來實現分散式交易？

各位朋友是不是有跟我一樣的症頭？從 SSMS 看到下面的欄位順序就想要給它調整一下？

即使警告資料表會被重建，我們還去把警告給關閉。

在 SQL Server 2017 出來以前，要做欄位資料合併顯示大都用 FOR XML，SQL Server 2017 加入了一個貼心的語法 STRING_AGG，大幅簡化了原本使用 FOR XML 的語法，我們來看 STRING_AGG 要怎麼使用？