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

SQL Server中的用户定义数据类型是中间SQL用户应该知道和使用的吗？

使用UDT的优缺点是什么？

1> HLGEM..：

---

永远不要使用它们是我的建议.如果您不得不改变定义,那么您将处于一个受伤的世界.也许这已经有所改进,因为SQL Server 2000和更熟悉新版本的人可以告诉你现在是否可以安全地进入水中,但是直到我确认了这一点并且我自己通过测试检查了它,我不知道不要把它放在我的生产系统上.

有关详细信息,请查看此问题: 如何在Sql Server 2005中更改UDT的基本类型？

---

我从2000年开始使用它们,从未遇到过任何问题.我已经改变了其中几个......我经常使用它们来寻找需要自定义验证或约束的类型(自定义uuids等).我强烈推荐它们用于此用途,尤其是当您将系统构建到框架时.任何人使用毯子'不要使用它'几乎总是很好,无论它是什么功能.

2> Mark Brittin..：

---

我不使用基于代码的UDT,因为我不认为额外的复杂性保证了这些优点.我确实使用T-SQL UDT,因为它的额外复杂性非常小,因此优点是值得的.(感谢Marc_s指出我原来的帖子不完整!)

关于基于代码的UDT

可以这样想:如果您的项目有托管代码组件(您的应用程序)和数据库组件(SQL Server),您从数据库中定义托管代码中获得了哪些真正的优势？在我的经验中？没有.

部署更加困难,因为您必须向数据库部署添加程序集并在SQL Server中更改这些程序集,添加文件等.你还必须打开SQL Server中的CLR(不是什么大不了的事,但没有人向我证明这不会有性能/内存损失).最后,如果您只是将其设计到应用程序的代码中,那么您将拥有完全相同的功能.可能会有一些性能提升,但它确实让我觉得过早优化 - 特别是因为我不知道整体性能是否因CLR开启而关闭而受到影响.

注意:我假设您将使用SQL Server的CLR来定义类型.HLGEM谈到SQL Server 2000,但我不熟悉2000并且认为它只有UDF而不是外部定义的dll中的UDT(但是不要引用我......我真的不熟悉它!).

关于T-SQL UDT

T_SQL UDT可以仅在SQL中定义(转到SQL Server Management Studio中的"可编程性|类型|用户定义的数据类型").对于标准的UDT我会其实建议你掌握它们.它们非常简单,可以使您的DDL更加自我记录,并可以强制执行完整性约束.例如,我定义了一个"GenderType"(char(1),不可为空,保持"M"或"F"),确保在Gender字段中只允许适当的数据.

UDT总体上非常简单,但本文提供了一个很好的示例,说明如何通过定义规则来约束UDT中允许的数据,从而将其提升到新的水平.

当我最初回答这个问题时,我已经确定了复杂的,代码定义类型的想法(从前额到掌心).所以...谢谢马克.

---

UDT(用户定义的类型)不一定意味着"托管代码".您可以定义基于直接T-SQL的UDT并使用它.CREAET TYPE ZipCode FROM varchar(10)NOT NULL; 不是说它很棒并且推荐 - 但它不一定是托管代码....

3> 小智..：

---

Alex Papadimoulis 很好地解决了用户定义类型的问题.这方面的缺点已得到很好的说明.

我还想指出,该sp_bindrule功能已被弃用,正如Alex的帖子所述.我不确定它什么时候被弃用但是现在.事实上,规则已被弃用.

如果我想创建一个带限制的类型,我会考虑使用一个用户定义的表类型,并在相应的列上使用检查约束.这也为我提供了构建复杂数据类型的方法.