SQL Server中的用户定义数据类型是中间SQL用户应该知道和使用的东西吗？
使用UDT的优点和缺点是什么？
答案 0 :(得分：17)
从不使用它们是我的建议。如果您不得不改变定义，那么您将处于一个受伤的世界。也许这已经有所改进，因为SQL Server 2000和更熟悉新版本的人可以告诉你现在是否可以安全地进入水中，但是直到我确认了这一点并且我自己通过测试检查了它，我不知道不要把它放在我的生产系统上。
查看此问题以获取详细信息： How to change the base type of a UDT in Sql Server 2005?
答案 1 :(得分：13)
我不使用基于代码的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总体来说非常简单，但是this article提供了一个非常好的示例，通过定义规则来约束UDT中允许的数据，将其提升到一个新的水平。
当我最初回答这个问题时，我已经解决了复杂的，代码定义类型的想法（将手掌放到额头上）。所以...谢谢马克。
答案 2 :(得分：6)
用户定义类型的专家是Alex Papadimoulis addressed quite well。这方面的利弊得到了很好的说明。
我还想指出，{@ 1}}函数已被弃用，正如Alex的帖子所述。我不确定它什么时候被弃用但是现在。事实上，规则已被弃用。
如果我想创建一个带限制的类型，我会考虑使用一个用户定义的表类型，并在相应的列上使用检查约束。这也为我提供了构建复杂数据类型的方法。
答案 3 :(得分：0)
我不能真正推荐使用任何特定于sql实现的功能，这些功能会在您从mssql中扩展并迁移到另一个dbms时变得更难。对于我们的dwh dbs，我们从mssql开始，迁移到oracle，并从去年开始毕业于hp vertica。