用户定义数据类型(UDT)在 SQL Server 中是中级 SQL 用户应该了解和使用的吗?
使用 UDT 的优缺点是什么?
用户定义数据类型(UDT)在 SQL Server 中是中级 SQL 用户应该了解和使用的吗?
使用 UDT 的优缺点是什么?
我的建议是永远不要使用它们。如果您必须更改定义,那么您将陷入困境。也许自从 SQL Server 2000 以来有所改进,熟悉新版本的人可以告诉您现在是否可以安全地使用,但在我确认并进行测试之前,我不会将其用于生产系统。
请查看此问题以获取详细信息:如何在 Sql Server 2005 中更改 UDT 的基本类型?
我不使用基于代码的UDT,因为我认为额外的复杂性并不值得优势。我使用T-SQL UDTs,因为增加了很少的复杂性,所以优势值得一试。(感谢Marc_s指出我的原帖不完整!)
关于基于代码的UDTs
从这个角度来看:如果你的项目有一个托管代码组件(应用程序)和一个数据库组件(SQL Server),那么在数据库中定义托管代码真的有什么好处吗?就我的经验而言,没有。
部署会更加困难,因为你必须添加程序集到你的DB部署中,并在SQL Server中修改这些程序集、添加文件等。你还必须在SQL Server中启用CLR(不要紧,但没有人向我证明这不会有性能/内存惩罚)。最终,你将拥有与如果你只是将其设计为应用程序代码相同的东西。可能会有一些性能提升,但它确实让我觉得它是早期优化的例子——特别是我不知道是否由于开启 CLR 而导致总体性能下降。
注意:我假设您将使用SQL Server的CLR来定义您的类型。HLGEM谈论SQL Server 2000,但我不熟悉2000,我以为它只有在外部定义dll中的UDFs而不是UDTs(但不要引用我……我真的不熟悉它!)。
关于T-SQL UDTs
T_SQL UDTs可以仅使用SQL来定义(转到SQL Server Management Studio中的"Programmability | Types | User-defined Data Types")。对于标准UDTs,我确实建议您掌握它们。它们非常简单,并且可以使您的DDL更具自我记录性,并且可以强制实施完整性约束。例如,我定义了一个 "GenderType"(char(1),不可空,保存 "M" 或 "F"),以确保只允许适当的数据放入Gender字段中。
UDTs(用户定义类型)总体来说相当简单,但这篇文章给出了一个很好的例子,展示如何通过定义规则来限制允许在你的UDT中使用的数据。
当我最初回答这个问题时,我坚持认为应该使用复杂的代码定义类型(扇了一下脑门)。所以...感谢Marc。
sp_bindrule
函数已被弃用。我不确定它何时被弃用,但现在已经是这样了。实际上,规则作为一个整体也已被弃用。我不太建议使用任何特定于SQL实现的功能,因为当你从MSSQL扩展并迁移到另一个DBMS时会更加困难。对于我们的DWH数据库,我们最初使用了MSSQL,然后迁移到Oracle,去年毕业后又升级到了HP Vertica。