軟體主廚的程式料理廚房

如果資料庫都隸屬於同一台伺服器，資料庫之間要 JOIN 彼此的資料表是相對容易的，在有權限的前提下，只要在資料表的前面加上「[資料庫名稱].[結構描述]」，就能存取得到其他資料庫的資料表，就像這樣：[DB].[dbo].[Table]。

但是在 Entity Framework Core 中，似乎沒有那麼容易，通常一個資料庫會建成一個 DbContext，當我們直接把隸屬於不同 DbContext 的 DbSet 拿來做 Join，我們得到以下的錯誤訊息：

Cannot use multiple context instances within a single query execution. Ensure the query uses a single context instance.

每每要在 Azure SQL Database 建立資料庫，設定定序這一關一定都會卡住，我必須用鍵盤輸入定序的完整名稱，可是完整的名稱有幾個人能記得住？而它那個尋找定序的功能又不太好用，再加上官方又沒有 SQL Server 所有支援的定序資訊，所幸我就來把跟繁體中文相關的定序放到部落格上，以後要查就有。

有時候我們在測試環境想刪除所有的資料表，但不想要重建資料庫，因為 SSMS 的物件總管無法多選資料表的關係，所以我都是用寫 SQL 指令碼的方式來做這一件事情，直到我無意中翻到了 StackOverflow 的這篇貼文才知道不用寫 SQL 指令碼也能做得到。

講到資料庫的唯一值，第一個我們會想到就是主索引鍵（Primary Key），那同一個資料表內除了主索引鍵之外會不會有其他的唯一值？我之前遇過的一個需求就有，它是一個部落格的功能，讀者可以收藏文章，同一篇文章不能重複收藏，而讀者可以對已收藏的文章進行任意的排序，所以「讀者 ID + 文章 ID」就成了資料表的主索引鍵，而「讀者 ID + 序號」就是資料表中的另一組唯一值。

這天客戶跑來跟我說「資料庫壞了，無法新增資料！」，出現了下面這段錯誤訊息：

Could not allocate space for object 'dbo.XXX'.'PK_XXX' in database 'YYY' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

很明顯，這段訊息告訴我們是儲存空間已滿，可是我前幾天才維護過，按照資料增加的速度，不會那麼快才對，來問問看使用者做了什麼事？

這陣子我們系統的錯誤通知出現了一個沒看過的訊息：

The query processor could not start the necessary thread resources for parallel query execution.

翻成中文是「查詢處理器無法為平行查詢的執行啟動必要的執行緒資源」，簡單來說就是「資料庫很忙，執行緒不夠用。」，而且根據幾個關鍵字 Thread、Parallel、Query，我們也大概能知道是平行處理的問題，知道了方向就可以開始著手調查了。

一個專案的結束，總不能船過水無痕，得留下些什麼。除了原始碼，資料庫內的資料也經常是需要被封存的對象，在地端的 SQL Server 通常只要將 MDF、LDF 檔案封存起來就可以搞定了，而雲端的 Azure SQL Database 沒有 MDF、LDF 檔案，取而代之，我們可以改用「匯出（Export）」的方式，將整個資料庫的資料給弄出來。

我們或多或少應該都有遇過一種情況，就是某一些資料表 JOIN 起來的查詢較為緩慢，面對這類執行時間較長的查詢，我們第一步是先進行資料表本身的效能調校，調校之後如果查詢還是需要一點時間，又剛好我們的資料庫系統是使用 SQL Server 的話，那我們可以考慮為查詢建立 Indexed View 試試看。

上一篇文章大致地了解了 SQL Server 登入及使用者之間的關係，登入只是個開始而已，只是能進到 SQL Server 而已，這時候還不能存取任何資料庫物件，還需要得到授權，要在 SQL Server 授權存取資料庫物件，就不得不提到「使用者（User）」及「角色（Role）」。

當我們建立了一個 SQL Server 實例之後，在開始處理資料之前，如果是對資安意識相對高一點的開發者，應該會有一個步驟是為我們的應用程式建立帳號，並且授予相對應的權限，而不會用 sa 走天下，當我們建立了一個登入時，通常會去使用者對應的頁面勾選對應的資料庫，此時，SQL Server 也會幫我們建立一個與登入名稱一樣的使用者，我們可能沒有感覺，但是 SQL Server 的登入及使用者其實是拆開來的。