主页 / dba / 问题 / 20283
Accepted
David George
Asked: 2012-07-03 09:46:04 +0800 CST

在中央数据库中创建函数还是在每个数据库中重复？

  • 772

我的一位开发人员编写了一个类似于 VB.Net 函数 (LastIndexOf) 的 SQL 函数，并希望发布它。我的问题是将它放在中央数据库中而不是放在每个用户数据库中的原因是什么？

开发人员试图将它放在他的主数据库上的 sys 模式中，这样他就不必限定从用户数据库对它的调用......叹息

但是我不确定将它（显然不是主数据库）与每个用户数据库集中起来的有效借口是什么？

sql-server performance

3 个回答

  1. Best Answer

    我更喜欢这样做的方式：将函数放在实用程序数据库中，并在每个常规数据库中创建它的同义词。这样您就可以两全其美：

    1. 只有一个对象的副本需要维护
    2. 开发人员不必提供由三部分或四部分组成的名称

    例如

    USE UtilityDB;
GO
CREATE FUNCTION dbo.LastIndexOf(...) ...
GO
USE otherDB;
GO
CREATE SYNONYM dbo.LastIndexOf FOR UtilityDB.dbo.LastIndexOf;
GO

    这对于 CLR 功能特别强大，因为更改/部署这些功能需要额外的管理开销。

    这比使用 master 更可取（并将其标记为系统对象，不能保证可向前移植）。不过，我很想知道您的开发人员希望如何在sys模式中创建他的函数。

    我确实理解在 500 个数据库中维护一个函数的多个副本实际上并不比维护一个副本更困难，但是拥有多个副本实际上只有在您确实有异常时才有好处（例如，客户端 A 希望他们的函数以不同的方式处理 NULL，或者其他的东西）。在这种情况下，我会将同义词保留在所有其他数据库中，并仅在该数据库中引入该函数的特殊版本。

    （当然，这假设该函数不依赖于客户端数据库中的任何数据访问 - 这肯定会使事情复杂化。）

    • 12

  2. 我将不得不不同意亚伦（以及接受的答案）。

    Aaron 的方法是我喜欢处理“DBA 东西”例如维护脚本的方式。我永远不想使用将由用户数据库调用的库函数来执行此操作。

    为什么？您将前往相当于DLL Hell的数据库。

    不兼容的版本

    ...在 Windows 2000 之前，Windows 易受此攻击，因为 COM 类表在所有用户和进程之间共享。只有一个 DLL/EXE 中的一个 COM 对象可以声明为在系统上具有特定的全局 COM 类 ID。如果任何程序需要创建该类的实例，它会得到当前集中注册的实现。结果，安装安装公共对象的新版本的程序可能会无意中破坏以前安装的其他程序。

    在运行 .net 2.0 应用程序的服务器上安装 .net 4.5 会发生什么？没什么，你的应用程序继续使用 2.0 框架。在托管 3 个应用程序数据库的服务器上更新您的 LastIndexOf 函数（作为其中一个升级的一部分），会发生什么？这三个现在都在使用最新版本。

    另一种方法是SQL#采用的方法。这安装到每个用户数据库的模式中，因此您可以安全地升级 Application-X 的数据库，而不会危及 Application-Y 的稳定性。

    如果您在严格控制的变更管理环境中工作，您将别无选择，如果不测试组件的所有使用者，您将无法升级共享组件。如果你在某个更“快速和宽松”的地方工作，你可以自由地冒险通过补丁/升级无意中破坏某些东西。

    • 5

  3. 这个问题的答案取决于我们谈论的是 T-SQL 对象还是 SQLCLR 对象。处理 SQLCLR 对象时需要考虑不同的（甚至更多）因素。

    就 T-SQL 对象而言，这里的两个答案都提出了有效的观点。正如@Aaron 的回答中所述，中央数据库非常方便，并且可以使用同义词使一些数据库指向共享资源和一些使用本地资源变得容易。但是，马克的回答中提出的关于由于更强的依赖性而增加风险的观点不容忽视。

    但是，如果您正在处理 SQLCLR 对象，那么您首先需要考虑我在以下答案中提出的所有要点：

    如何从性能的角度更好地使用 CLR 函数（在每个数据库中重复或具有通用功能）？

    • 0

相关问题