如果我們接手維護一個資料庫,裡面的 Table、View、Stored Procedure、Function、Trigger 相依鏈錯綜複雜,想要定位發生問題的區塊,搞得像盜墓一樣,這天我無意間發現 SSMS(SQL Server Management Studio)有一個「檢視相依性
」的功能,有助我們來釐清資料庫物件的相依鏈。
[小菜一碟] 無意中發現 SSMS(SQL Server Management Studio)有一個「檢視相依性」的功能
- 1323
- 0
- SQL Server
如果我們接手維護一個資料庫,裡面的 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 啊,我想再看到每個分店每月銷售額跟他們最好及最差的那一個月相比,看看差了多少百分比。」,當然沒問題,付錢就行。
上一篇文章提到依日期彙總結果,這時候老闆又開需求了「Johnny 啊,能不能幫我多加一個欄位,讓我看到每個分店當月銷售額與上個月銷售額相比的成長百分比?」,這個需求也很常出現在我的程式設計生涯當中,我們來看看在 SQL Server 中怎麼來實現。