SQL Server 中的用户定义数据类型有多酷？

Question

用户定义数据类型（UDT）在 SQL Server 中是中级 SQL 用户应该了解和使用的吗？

使用 UDT 的优缺点是什么？

- David Vidmar

---

手动方法虽然有些麻烦，但非常实用，曾经救过我的一命：参考链接：https://dev59.com/pnM_5IYBdhLWcg3waiiJ - Jatin Kumar

Answer 1

我的建议是永远不要使用它们。如果您必须更改定义，那么您将陷入困境。也许自从 SQL Server 2000 以来有所改进，熟悉新版本的人可以告诉您现在是否可以安全地使用，但在我确认并进行测试之前，我不会将其用于生产系统。

请查看此问题以获取详细信息：如何在 Sql Server 2005 中更改 UDT 的基本类型？

- HLGEM

---

自2000年以来我一直在使用它们，从未遇到任何问题。我曾经更换过几个... 我经常用它们来处理需要自定义验证或约束条件的类型（如自定义uuid等）。我强烈推荐在构建一个系统到框架时使用它们。任何人都告诉你“不要使用它们”几乎总是错误的，无论涉及哪些功能。 - Dawesi

Answer 2

我不使用基于代码的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。

- Mark Brittingham

---

UDT（用户定义类型）并不一定意味着“托管代码”。您可以定义一个基于纯T-SQL的UDT并使用它。 CREATE TYPE ZipCode FROM varchar(10) NOT NULL; 并不是说这是最好的做法和推荐方式 - 但它并不一定是托管代码... - marc_s

Answer 3

用户定义类型的优点已经被Alex Papadimoulis很好地解释了。缺点已在此处得到充分阐述。

我还想指出，如Alex的帖子所述，sp_bindrule函数已被弃用。我不确定它何时被弃用，但现在已经是这样了。实际上，规则作为一个整体也已被弃用。

如果我想创建一个带有限制的类型，我会考虑在适当的列上使用带有检查约束条件的用户定义表类型。这也给了我构建复杂数据类型的一种方法。

- Katherine Elizabeth Lightsey

---

我的主要用途与Alex所描述的相同（更好的约束条件）。 - Dawesi

Answer 4

我不太建议使用任何特定于SQL实现的功能，因为当你从MSSQL扩展并迁移到另一个DBMS时会更加困难。对于我们的DWH数据库，我们最初使用了MSSQL，然后迁移到Oracle，去年毕业后又升级到了HP Vertica。

- Werner Falkmann