访问 SQLCLR 触发器内的触发/父表名

Question

我正在用 C# 创建一个相对简单的 SQL CLR。

此 CLR 的工作是将事件发布到 Azure 事件网格主题。

我希望能够从任意数量的表的任意数量的触发器中调用这个特定的 CLR（实际上会很少）。

鉴于下面的核心代码，如何准确检索导致/触发触发器的表的名称？我不知道从哪里开始。

我希望能够删除SqlTrigger 属性并以某种方式访问​​var table 属性的表名。

// I Would like to leave the attribute commented out
//
//[Microsoft.SqlServer.Server.SqlTrigger(Name = "PublishToEventGridTrigger",
//     Target = "NamesOfThings", Event = "FOR UPDATE, INSERT, DELETE")]
public static void PublishToEventGridTrigger()
{
    // TODO - How should these settings be handled?     
    //        Not sure if config files are accessible... To test..
    // ***************************************************************

    string topicHost = "https://####.eventgrid.azure.net/api/events";
    string topicKey = "####";

    // TODO - Get Table name for this
    var table = "How Do I set This";
    string eventType = $"##.{table}.{SqlContext.TriggerContext.TriggerAction.ToString()}";

    // ***************************************************************

    try
    {
        // extract data involved in trigger
        // Create the Event object
        EventGridEvent evt = new EventGridEvent("QWDBEvent", eventType, new
                      TriggerData(SqlContext.TriggerContext, SqlContext.Pipe));

        // Publish the event
        Event.Publish(topicHost, topicKey, evt);
    }
    catch (Exception ex)
    {
        //TODO - how do we handle these through SQL CLR? 
        // Going with a fire-and-forget for now    
        SqlContext.Pipe.Send($"Failure firing {ex.Message}");        
    }
    SqlContext.Pipe.Send($"Trigger fired");
}

Answer 1

这不是本机支持的，也不是很容易实现。我实际上有一个模型可以做到，但还没有时间发布它。当然不是直截了当。目前，您可以查看此问题的两个答案：

SQL CLR Trigger - get source table

当我清理并发布我的解决方案时，我会更新这个答案。

然而，虽然您说只有少数表会应用此功能，但请记住，触发器是在 DML（甚至DDL) 语句是其中的一部分。这有两个后果：

1. 触发器花费的时间越长，DML/DDL 操作花费的时间就越长，因此对象上的锁被持有的时间越长。这会对并发/性能产生不利影响。将 DML / DDL 语句与本地（内联网 / 同一网络）服务的 Web 服务调用联系起来让许多人感到紧张，但整个互联网正在将危险的、高度可变的风险引入一个应该相当简单的过程。当然，如果您使用的是 Azure VM 或 Azure SQL 托管实例，那么延迟可能足够低，以保证“足够”安全。无论哪种方式，要非常谨慎！ （明确一点：使用 T-SQL 触发器执行 SQLCLR 存储过程并不能减轻这种风险；这仍然是同一个事务）
2. 如果触发器失败/抛出错误，默认情况下将中止事务并回滚 DML（或 DDL）操作。这是预期的行为吗？通常未能记录事件不应该中止操作本身，对吧？因此，您可能需要吞下错误（或者至少将其写入文本文件）。

您应该能够通过设置 Service Broker 来处理调用日志服务，从而将 DML/DLL 操作与日志片段分离。在这种情况下，您会：

1. 使用 T-SQL 触发器
   1. 通过以下方式获取表名：

      SELECT tab.[name]
      FROM   sys.objects tab
      WHERE  tab.[object_id] = (
                        SELECT trg.[parent_object_id]
                        FROM sys.objects trg
                        WHERE  trg.[object_id] = @@PROCID
                               );
      

   2. 收集任何其他信息以记录，可能来自INSERTED 和/或DELETED 表（在此之后您将无法访问这些；尽管您可以将这两个表中的数据重新打包为 XML 以发送作为 Service Broker 消息的一部分——例如 SELECT * FROM inserted FOR XML RAW('ins');)
   3. 为 Service Broker 排队包含收集到的信息的消息
2. 使用服务代理
   1. 将从 DML / DLL 操作异步处理消息
   2. 可以执行SQLCLR存储过程，传入T-SQL触发器中收集的信息，调用日志服务（无论是内网还是外网）

请记住（因为您提到从 INSERTED 和 DELETED 表中获取受影响的 PK 值）如果 DML 操作影响多行（即从不假设 DML 操作只有一行）。