目前關於SQL Server腳本頂部USE關鍵字的爭論（或者更激烈的爭論）正在進行。在SQL Server中使用USE關鍵字是不好的做法嗎？
我們的一位開發人員表示，衆所周知，使用USE關鍵字是不好的做法。他的觀點是，如果開發人員使用正確的登錄名，那麼應該自動指定適當的數據庫，而USE關鍵字只會鼓勵濫用SA帳戶。在我們的現場，他的擔憂是由於過去曾發生過濫用SA的事實，儘管正在採取措施消除這個問題。
其他開發者認爲，由於我們工作的性質（我們經常在一天內處理多個數據庫，有時在很短時間內轉換任務），使用USE關鍵字有助於提高可讀性，以提醒哪些數據庫我們正在努力並防止在錯誤的數據庫中意外使用SP。
經過在互聯網上的大量搜索後，我只能找到證明其使用的示例，並且在「良好實踐」環境中找不到任何關於它的討論。儘管USE是一個非常普遍的詞，但搜索卻受到了阻礙！
這是什麼標準？ USE關鍵字是非常糟糕的做法，還是將它作爲後備方案很好？
我將不勝感激任何輸入 - 在此先感謝！
我一直在使用SQL Server的約13年了，20和所有那個時代是一個DBA因爲我從來沒有聽說過對符合條件的數據庫中的一個參數，你會被使用在腳本的頂部。我從來沒有聽說過最好的做法，但我認爲這更多的是因爲它是一個基本的東西。
首先一個常見的最佳實踐是，只有DBA應該有權訪問SA帳戶，並且他們不應該使用它。沒有開發人員應該具有系統管理員權限，並且DBA應該在其AD帳戶上擁有系統管理員，或者擁有單獨的SQL Server登錄名，以便他們能夠負責。 SA過於通用，只能用於緊急情況（以及那些堅持說他們不能沒有它的生活的供應商，但不要讓我開始使用它）。許多商店的標準是禁用和/或重命名SA賬戶。所以，這照顧你的SA濫用問題。
其次，大多數人在具有多個數據庫的環境中工作。您可能會問您的開發人員他是否認爲他們應該爲每個數據庫單獨登錄，以便默認數據庫對於該腳本是正確的？他是否計劃在腳本的開頭指定要使用的登錄名而不是數據庫？
第三，我在當前位置查看了很多腳本，並且我在其他位置查看了更多腳本。我不得不處理的最令人煩惱的事情之一是不知道腳本應該運行的數據庫（或服務器）。所以是的，請在您的腳本的頂部放置一個USE。如果您需要將數據庫更改爲一半，請在此處添加另一個USE語句。如果你真的討厭使用USE，那麼你應該把三個部分名稱，以便數據庫是合格的。特別是因爲作爲一個與所有數據庫一起工作的DBA（我的一些服務器有100個，而且我看到有1000個數據庫的服務器），我將我的默認數據庫保留爲主數據庫。
借調，我總是在腳本的頂部使用（以及註釋中的服務器名稱），如果這是您的包，您可以隨時將它留下評論。 – twoleggedhorse
參數並不是在腳本的頂部是否可以編寫USE關鍵字 - 這是可以接受的，建議在對數據庫進行更改時採用&好的做法。
更明確的說，是否可以接受甚至有必要在存儲過程頂部編寫USE關鍵字，而不是使用數據庫登錄名來爲您設置默認數據庫，在這種情況下，存儲過程將始終編譯到正確的數據庫（而不是主數據庫）中。此外，通過對數據庫使用登錄可確保您只有權限在該數據庫的上下文中執行操作，這會強化更嚴格的安全性/權限，從而降低開發人員針對錯誤數據庫中的表應用更新的風險。
我很欣賞DBA在第一次回覆中的看法，但他們對開發人員有不同的觀點，因此從兩位開發人員& DBA聽到有關此問題的其他觀點會很有趣。
如果您在共享環境中運行臨時DDL腳本，您真正要問的是「非託管代碼部署的最佳做法是什麼？」，答案是「不要做它們」。添加USE指令只是通過創建另一個（它強制你的上下文）來解決一個問題（它強制你的上下文）。您只是創建了非常難以追蹤和管理的附加依賴項。
解決問題的根源：開發人員失去了他們的環境意識。默默地改變他們的語境並不會讓他們意識到。
我首先想要禁用sa登錄，我會努力爭論。接下來，我會爭辯將大家的默認數據庫，特別是sa更改爲空白數據庫。這消除了大多數潛在的損害，並且如果您從該數據庫中刪除所有用戶權限，還會立即向忘記切換的開發人員提供反饋。如果你真的想獲得一些樂趣，創建一個DDL觸發器，如果有人在默認數據庫上運行腳本，就會向團隊發送電子郵件。
（作爲對這個問題被置於保留的迴應）。這個問題的目的不是要徵求意見，而是要幫助我們根據其他用戶的經驗和其他開發團隊/公司的正式標準構建最佳實踐文檔，針對特定領域進行徹底的互聯網研究尚無定論。 – Steve