我正在尝试执行此查询,但由于 azure 数据仓库不支持用户定义(创建类型)类型。我想在存储过程中使用它。
CREATE TYPE DataTypeforCustomerTable AS TABLE(
PersonID int,
Name varchar(255),
LastModifytime datetime
);
GO
CREATE PROCEDURE usp_upsert_customer_table @customer_table DataTypeforCustomerTable READONLY
AS
BEGIN
MERGE customer_table AS target
USING @customer_table AS source
ON (target.PersonID = source.PersonID)
WHEN MATCHED THEN
UPDATE SET Name = source.Name,LastModifytime = source.LastModifytime
WHEN NOT MATCHED THEN
INSERT (PersonID, Name, LastModifytime)
VALUES (source.PersonID, source.Name, source.LastModifytime);
END
GO
CREATE TYPE DataTypeforProjectTable AS TABLE(
Project varchar(255),
Creationtime datetime
);
GO
CREATE PROCEDURE usp_upsert_project_table @project_table DataTypeforProjectTable READONLY
AS
BEGIN
MERGE project_table AS target
USING @project_table AS source
ON (target.Project = source.Project)
WHEN MATCHED THEN
UPDATE SET Creationtime = source.Creationtime
WHEN NOT MATCHED THEN
INSERT (Project, Creationtime)
VALUES (source.Project, source.Creationtime);
END
有没有其他方法可以做到这一点。
最佳答案
您在这方面遇到了一些挑战,因为您尝试转换的大部分内容都不是在 ASDW 上执行操作的方式。
首先,正如您所指出的,不支持 CREATE TYPE,并且没有等效的替代方案。
接下来,代码似乎正在对表进行单次插入。这对 ASDW 来说确实很糟糕,性能会很糟糕。
接下来,ASDW 还没有 MERGE 语句。这是因为 UPDATE 并不是处理不断变化的数据的最佳方式。
最后,存储过程在 ASDW 上的工作方式略有不同,它们不会被编译,而是在每次调用过程时进行解释。存储过程非常适合大块表级逻辑,但不建议用于单行操作的大量调用。
我需要更多地了解用例才能提出具体建议,但一般来说,您需要在表格中而不是行中进行思考。特别要关注处理 ELT 的 CREATE TABLE AS (CTAS) 方式。
这是一个很好的链接,它展示了如何使用 CTAS 处理合并/更新插入的等效内容:
正如您将看到的,它一次处理两个表,而不是一行。这意味着您需要检查调用存储过程示例的逻辑。
如果您专心在 CTAS 中完成所有工作,并分别围绕分发进行操作,那么您就已经在拥有高性能数据仓库的道路上了。
关于azure - SQL 中是否有 CREATE TYPE 的替代方案,因为 Azure SQL 数据仓库不支持 CREATE TYPE,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55178434/