设想：
我将一个字符串插入到二进制字段 (CONTEXT_INFO) 中，然后尝试将其取出并将其转换回字符串。当我这样做时，结果字符串的长度为 128，因为它有尾随空字符。
例子：
DECLARE @string VARCHAR(128)
DECLARE @binary VARBINARY(128)
SET @string = 'abcdefg'
SET @binary = CONVERT(VARBINARY(128), @string) --0x61626364656667000000...
SET CONTEXT_INFO @binary
SET @binary = CONTEXT_INFO()
-- I would like to change the following line so it trims trailing null chars
SET @string = CONVERT(VARCHAR(128), @binary)
SELECT
@binary AS [binary],
DATALENGTH(@binary) AS [binary.Length], --128 as expected
@string AS [string],
DATALENGTH(@string) AS [string.Length] --This is 128, but I need it to be 7
问题：
当我将二进制字段转换为字符串时，如何修剪尾随的空字符？
设想：
每次在表中插入/更新/删除数据/从表中/从表中插入/更新/删除数据，都需要执行多个不相关的业务逻辑项。
题
鉴于解决方案是使用数据库触发器，哪个选项更好？：
1) 每个操作一个触发器（插入/更新/删除）：
I_Table - 在插入上执行U_Table - 在更新时执行 D_Table - 在删除时执行每个触发器将处理多个不相关的业务逻辑项。
或者
2) 每个操作的多个触发器被关注点隔离：
I_Table_Logging - 用于登录插入I_Table_RI - 用于在插入上实施参照完整性I_Table_BL - 用于在插入上执行业务逻辑U_Table_Logging - 用于登录更新U_Table_RI - 用于在更新中强制执行参照完整性U_Table_BL - 用于在更新上执行业务逻辑D_Table_Logging - 用于登录删除D_Table_RI - 用于在删除时强制执行参照完整性D_Table_BL - 用于在删除时执行业务逻辑我更喜欢选项 2，因为单个代码单元有一个关注点。我不是 DBA，对 SQL Server 的了解足以让我变得危险。
不得更改数据库的架构和模式。模式中有几个地方应该使用显式关系强制执行，但不幸的是还不能更改。这就是我需要手动强制执行参照完整性而不是依赖显式关系的原因。
是否有任何令人信服的理由在一个触发器中处理所有问题？我特别关注性能、执行顺序和回滚。