CLR 以及儲存配置值的位置

我正在尋找替換 CLR 程式碼（SQL 2012）中的一些硬編碼值，我在這裡遇到了配置文件的使用 - https://stackoverflow.com/questions/16177769/assembly-configuration-clr-stored-procedure。一些回复說最好將鍵/值對保存在表中而不是配置文件中，一個原因是 SQL 2014+ 不支持它。

我們的開發人員說它在 SQL 2014 中執行良好，所以我對此並不關心，但我確實認為將值儲存在本地數據庫的表中會是一個更好的主意。

1. 其他人能否確認 SQL 2014+ 支持或不支持配置文件？
2. 是否有任何關於在表中儲存鍵/值對的最佳實踐的文件，或者有任何理由不這樣做？

我很確定sqlservr.exe.config配置文件在 SQL Server 2014 中工作，但需要幾分鐘來確認。我也很確定它不是“官方”支持的，因此不“推薦”使用，但有時我發現它使用起來很方便並且已經這樣做了。

數據的位置是否應該在配置文件或表中很大程度上取決於整體需求。值多久會改變一次？您說的是“硬編碼”，但有時每個版本的查找值可能會發生變化。你想必須執行一個UPDATE語句，還是想辦法在你的建構過程中包含維護這個配置文件（你需要找到一些方法來確保它總是在那裡）。

此外，在 .NET / SQLCLR 程式碼之外是否需要這些值？將它們放在一個表中使它們對所有現有查詢更可用。

此外，是否需要在這些值的數據庫之間進行分離？使用配置文件，它在該實例的所有應用程序域之間共享。配置表可以很容易地放置在公共數據庫中（假設多個數據庫可能需要這些值）或放置到每個數據庫中。您可以在配置文件中分隔值，但這需要為鍵使用不同的名稱，這使得在 .NET 程式碼中標準化變得更加困難。

如果只讀和通用/共享足夠有意義，那麼為什麼不開始嘗試配置文件方法，如果您發現它不滿足您的需求的任何原因，只需將其移至儲存在桌子。畢竟，這兩種方法都不需要那麼多小時的工作，而且它們之間的時間差可以忽略不計，所以如果你確實需要切換到另一種方法，也不會花費太多。

筆記：

1. 在此問題中連結的 StackOverflow 問題中，@David 的回答表明該配置文件自 SQL Server 2014 起不再有效。我剛剛測試並確認它確實在 SQL Server 2014 甚至 2016 上有效！
2. 在此問題中連結的 StackOverflow 問題中，@Remus 的回答指出，由於配置文件與 SQL Server 斷開連接並且可能不在相關伺服器上，或者可能與它們不同步，因此首選儲存在數據庫中。這一點不應該被忽視，這些問題應該有助於團隊從整體上了解應用程序的執行方式，從而做出更明智的決定。但是，肯定有一些場景不存在此類問題，並且允許建構過程確保此配置文件在每個環境中都存在，就像建構過程對 Web 伺服器上的配置文件進行相同的檢查等一樣。
3. 在連結問題中@Remus 的回答中引用的部落格中，作者提到了一個“問題”，即在嘗試讀取 AppSettings 時出錯，並註意到解決方法為 call ConfigurationManager.ConnectionStrings.Count;。那是正確的。但是，您不需要每次都打那個電話。它只需要在 App Domain 的生命週期內完成一次。因此，將它放在靜態類建構子中就可以了，如下所示：

static _your_class_name_here_()
{
   int _BugBeGone = ConfigurationManager.ConnectionStrings.Count;
}

不，你不需要<connectionStrings>在你的配置文件中有一個部分來完成上述工作。 4. 同一篇部落格文章還提到配置文件只讀取一次，當創建應用程序域時，您需要重新啟動實例 - 或者可能解除安裝應用程序域 - 以便對配置進行任何更改創建應用程序域後的文件對您的程式碼可見。第一部分是正確的：配置文件被載入一次並在 App Domain 的生命週期內記憶體。但是，您不需要重新啟動實例來刷新配置值，甚至不需要解除安裝應用程序域。你只需要打電話：

ConfigurationManager.RefreshSection("appSettings");

但是不要對每個呼叫都這樣做，除非函式或儲存過程是為了偶爾執行。如果這是每秒至少執行一次或更頻繁的東西，那麼創建一個單獨的函式或儲存過程來執行刷新並在必要時執行它。

引用自：https://dba.stackexchange.com/questions/167896