主页 / dba / 问题 / 167896
Accepted
Greg
Asked: 2017-03-23 08:13:57 +0800 CST

CLR 和存储配置值的位置

  • 772

我正在寻找替换 CLR 代码（SQL 2012）中的一些硬编码值，我在这里遇到了配置文件的使用 - https://stackoverflow.com/questions/16177769/assembly-configuration-clr-stored-procedure。一些回复说，与配置文件相比，将键/值对保存在表中更好，原因之一是它在 SQL 2014+ 中不受支持。

我们的开发人员说它在 SQL 2014 中运行良好，所以我不关心这一点，但我确实认为将值存储在本地数据库的表中是一个更好的主意。

  1. 其他人可以确认 SQL 2014+ 是否支持配置文件吗？
  2. 是否有任何关于在表中存储键/值对的最佳实践的文档，或者有什么理由不这样做？
sql-server sql-server-2012

1 个回答

  1. Best Answer

    我很确定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 时出错，并且注意到一个解决方法是调用ConfigurationManager.ConnectionStrings.Count;. 那是对的。但是，您不需要每次都进行调用；在 App Domain 的生命周期内只需执行一次。因此，将它放在静态类构造函数中就可以正常工作，如下所示：

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

      不，你不需要<connectionStrings>在你的配置文件中有一个部分来让上面的工作。

    4. 同一篇博文还提到配置文件只读一次，即创建 App Domain 时，您需要重新启动实例——或者可能卸载 App Domain——以便对配置进行任何更改创建 App Domain 后的文件对您的代码可见。第一部分是正确的：配置文件加载一次并在 App Domain 的生命周期内缓存。但是，您不需要重新启动实例来刷新配置值，甚至不需要卸载应用程序域。你只需要打电话：

      ConfigurationManager.RefreshSection("appSettings");

      但是不要在每次调用时都这样做，除非函数或存储过程是偶尔运行的。如果这是每秒至少运行一次或更频繁的东西，则创建一个单独的函数或存储过程来执行刷新并在必要时执行它。

    • 3

相关问题