是创建用户定义的类型而不是使用现有类型的最佳实践？在我的预览工作场所中，所有基本类型都是预定义的，这是最佳实践吗？它有什么优点和缺点。
非常感谢！
答案 0 :(得分：5)
在MS SQL Server中 - 这个想法很棒。但是，对他们来说有一个很大的但是：一旦使用它们就无法更改它们，因为没有ALTER TYPE ....语句。这可能是一个很大的麻烦。
考虑一下：你有一个书店应用程序，它有一个用户定义类型ISBN = VARCHAR（10） - 就像一个魅力。现在，国际委员会决定将ISBN字段增加到13个字符 - 遗憾的是，没有ALTER TYPE ISBNType.....因此您唯一的选择是基本上删除所有数据库中的所有类型的列，然后重新创建类型它的新形式，并再次重新创建所有这些列。
这个想法非常好，我很乐意使用它 - 但在目前的状态下，在我看来，这是不可用的，这是不幸的。
马克
答案 1 :(得分：2)
有点晚了，但是......我的2点。
用户定义的类型在概念和逻辑模型中履行域的角色，因此，如果要在物理数据库中实现逻辑数据模型，则使用用户定义的类型将是最接近的近似值。这将带来诸多好处，例如使用可以自动传输到实现的图形模型，比不使用UDT时更好。
使用域可以检测在SSN字段中存储邮政编码的尝试，并在运行时（甚至编译时）将它们捕获到数据库中。这将使您能够在应该强制实施的公司范围内实施业务规则：在数据到达存储的位置。其他任何地方都是对用户的礼貌，但这是他们绝对必须执行的地方，以确保没有人绕过他们。
此外，ANSI SQL：1999中定义的UDT封装了方法，并且可以进行子类型化。这意味着可以在数据库中更改处理约束的业务规则中的某些更改，而无需触及实现。
但是......因为目前实施的UDT还有很多不足之处。我甚至不确定SQL Server是否如所描述的那样实现了标准，甚至不太确定Oracle。即使他们这样做，使用UD工具，ETL工具或其他相当简单的工具时，使用UDT的缺点也会立即变得明显：他们通常不了解UDT，即使他们这样做，他们也赢了＃ 39;能够使用它们，因为大多数都基于基本类型（int，char和日期/时间）。
对于报告工具，我们考虑一个具有字段组合的UDT。现在，与数据库无关的ETL工具如何能够理解该类型？它必须能够理解结构才能显示它，或者用它来进行计算。对于每个支持的数据库而言 - 这是一项艰巨的任务由于没有人使用UDT，他们不会这样做。这是一个恶性循环，但我们仍然需要忍受它。
除此之外，大多数数据库中的UDT支持也不是那么热门。改变类型可能非常困难。虽然语法应该在任何地方都相同，但它们的管理在SQL：1999中是未定义的，因此在任何地方都是不同的。例如，尝试在sql server中更改UDT的所有者。过去相当困难 - 不确定SQL Server 2016，但鉴于UDT看起来不像是一个重点领域，我不希望在该领域有重大改进。
最后，如果您将非常复杂的代码添加到UDT，那么您将遇到在缺少良好调试选项的环境中编程的旧问题。这对任何事都没有帮助。
所以：如果您完全控制数据库并且所有交互都通过您的软件，那么UDT可能非常有用。如果没有，他们可能是一个巨大的痛苦的脖子。在你的场景中是哪种情况，只有你能说出来。
答案 2 :(得分：1)
How cool are User Defined Data Types in MS SQL Server?
就个人而言，我不会使用它们，但我已经看过了。一个问题是客户端代码至少只识别MS SQL Server的基本类型IIRC。和版本之间的可移植性/行为。