我的DBA告诉我使用用户定义的SQL数据类型来表示地址，然后在users表中使用该新类型的单个列而不是多个地址列。我以前从未这样做，我想知道这是否是一种常见的方法。
此外，获取此信息的最佳位置是什么？是产品特定的吗？
答案 0 :(得分：3)
据我所知，至少在SQL Server世界中，UDT使用不多。
UDT的问题在于您无法轻松更新它们。一旦在数据库中创建和使用，它们就像是一成不变的。
没有“创建或更改（UDT）”命令:-(所以要改变一些东西，你必须做很多改组 - 可能会复制掉现有数据，然后从其他表中删除大量列，然后丢弃你的UDT，使用新结构重新创建它并重新应用数据和所有内容。
这太麻烦 - 而且你知道：会改变！
目前，在SQL Server领域，UDT只是个不错的主意 - 但实际上却很糟糕。我不建议广泛使用它们。
马克
答案 1 :(得分：1)
关于如何在数据库中表示地址，SO还有许多其他问题。 AFAICR，它们都没有为此目的建议用户定义的类型。我不认为这是一种常见的做法;这并不是说这不是一个合理的方法。主要困难在于决定提供哪些方法来操纵地址数据 - 用于格式化数据以显示在信封上，或打印在表格上的特定位置，或更新字段，担心国际地址的许多后果等等。
定义用户定义的类型非常特定于产品。例如，在Informix中执行此操作的方式与在DB2和Oracle中完成的方式不同。
答案 2 :(得分：0)
我还宁愿避免使用用户定义的数据类型，因为它们的定义和可用性会使您的代码依赖于特定的数据库。
相反，如果您使用任何面向对象的语言，请创建组合关系以定义员工的地址（例如）并将地址存储在单独的表中。
EG。 Employees表和Employee_Addresses表。一名员工可以拥有多个地址。
答案 3 :(得分：0)
用户定义的SQL数据类型来表示地址
用户定义的类型可能非常有用，但邮件地址不会像其中一种情况一样跳出来（至少对我来说）。你的邮寄地址是什么？这是你在信封上打印给某人邮寄的东西吗？如果是这样，文本就会得到它的好处。如果您出于法律原因需要了解某人所处的状态，请单独存储，这不是问题。
此处的其他帖子批评了UDT，但我认为它们确实有一些惊人的用途。在将全文搜索实际集成到核心产品中之前，PostgreSQL已经将全文搜索作为基于UDT的插件进行了很长时间。现在，PostGIS是一个非常成功的GIS产品，它完全是一个基于UDT的插件（它具有GPL许可证，因此永远不会集成到核心中）。