自定义数据类型和#temp表

Question

在SQL Server 2008数据库中，我有一个自定义数据类型。在其中的一个存储过程中，我打算将该类型用作临时表的列类型，如下所示：

CREATE TABLE #SomeTable
(
    [some_column] UDT_SomeType,
    -- other columns 
)

显然我的尝试失败了，因为据我在谷歌上搜到的，UDT_SomeType 在 tempdb 中不存在（实际存储临时表的地方）。

UDT_SomeType 其实是 NUMERIC(19,9)，所以我暂时可以使用以下解决方法：

CREATE TABLE #SomeTable
(
    [some_column] NUMERIC(19,9),
    -- others columns  
)

然而，我认为这不是一个真正好的解决方案。这里是否有任何可以应用的最佳实践呢？

- Artem

---

请看这里：https://dev59.com/eGEi5IYBdhLWcg3wltMl - Kamil Gosciminski

@KamilG 我明白那个方法可以行得通，但是临时表还有其他列。所以你提供的解决方案只能在我定义一个新的表类型时才能应用。 - Artem

@Artem，你找到任何有用的解决方案了吗？ - Simone

Answer 1

重要信息：

这种解决方法不应该在任何SP或结构化查询中使用；它的唯一用途应该限于在受保护的环境中进行临时查询，以避免任何可能的不利影响。它只是为了演示，在特殊情况下，可以在临时表中拥有UDT。感谢@Marcel（请参见评论）指出这一点。

不幸的是，这并不是很直观，但通过一些脚本，您可以实现。我会保留一个小脚本来创建所有必需的类型，在需要时启动。

辅助脚本：

USE [tempdb]
GO
CREATE TYPE [UDT_SomeType] FROM NUMERIC(19,9)
GO

正常脚本：

USE [YOURDB]
GO

CREATE TABLE #SomeTable
(
    [some_column] UDT_SomeType,
    -- other columns 
)

- Simone

---

这是一个很好的解决方法。采用这种方法的努力是最小的。 - Artem

这种解决方法有几个缺点。首先，它是不可重入的。当代码的不同实例同时运行时，未定义哪个实例创建了UDT。其次，显式编写UDT的本机类型将UDT背后的概念推向荒谬的地步。它违反了DRY原则。 - Marcel

@Marcel，你说得完全正确。为自己辩护，我只能说我忘了提到当我使用这个解决方法时，只是运行一些临时查询，从未考虑将其放入任何存储过程中。再次阅读问题后，我发现提到了一个存储过程，所以我会在我的答案中加上一个大的警告。感谢您指出这一点。 - Simone