触发器中必须从INSERTED表显式获取LanguageID，不能假设自动可用；SQL Server用INSTEAD OF INSERT配合LEFT JOIN查LanguageDefaults表填充NULL字段，MySQL需用BEFORE INSERT SET NEW.field赋值，DEFAULT约束不支持动态查表。
触发器里怎么拿到当前插入的 LanguageID
SQL Server 或 MySQL 的触发器本身不直接暴露“当前语言环境”，必须依赖插入语句中显式提供的 LanguageID 字段。如果你的表结构里没有这个字段，INSERT 语句就无法传递上下文，触发器也就无从判断该填哪门语言的默认值。
常见错误现象是：触发器硬编码写死 LanguageID = 1，结果所有新记录都填了中文（或英文），完全忽略实际业务请求的语言偏好。
- 确保目标表包含
LanguageID列（INT 或 TINYINT，NOT NULL） - 插入时必须显式提供该值，例如：
INSERT INTO Products (Name, Description, LanguageID) VALUES ('Laptop', NULL, 2) - 如果应用层用 ORM（如 EF Core），需确认它确实把
LanguageID映射进 SQL 参数，而不是只传多语言视图字段
如何安全地填充 NULL 的多语言字段
触发器不能假设所有字段都为空才去填——有些字段可能被有意设为 NULL（比如暂不提供德语描述），所以得逐字段判断是否为 NULL 且有对应默认值可查。
典型做法是：从一个 LanguageDefaults 表查出该 LanguageID 下各字段的默认文本，再用 COALESCE 或 ISNULL 赋值。注意避免全表扫描。
-
LanguageDefaults表结构建议含：LanguageID,FieldName（如 'Name'、'Description'）,DefaultValue（NVARCHAR(MAX)） - 在
INSTEAD OF INSERT触发器中做填充更可控，避免AFTER INSERT引发二次更新开销 - 不要在触发器里写循环或游标——对批量
INSERT来说性能灾难，改用LEFT JOIN+ISNULL一次性处理
示例（SQL Server）：
CREATE TRIGGER tr_Products_Insert_Defaults
ON Products
INSTEAD OF INSERT
AS
BEGIN
INSERT INTO Products (Name, Description, LanguageID)
SELECT
ISNULL(i.Name, d_name.DefaultValue),
ISNULL(i.Description, d_desc.DefaultValue),
i.LanguageID
FROM inserted i
LEFT JOIN LanguageDefaults d_name
ON d_name.LanguageID = i.LanguageID AND d_name.FieldName = 'Name'
LEFT JOIN LanguageDefaults d_desc
ON d_desc.LanguageID = i.LanguageID AND d_desc.FieldName = 'Description';
END;
MySQL 和 PostgreSQL 的关键差异点
MySQL 不支持 INSTEAD OF 触发器（仅支持 BEFORE/AFTER），所以你得在 BEFORE INSERT 里用 SET NEW.Name = ... 赋值；而 PostgreSQL 支持 BEFORE INSERT ... FOR EACH ROW，但要注意它不允许多行 NEW 同时修改，得用 ROW 级逻辑。
- MySQL 中若字段是
NOT NULL，又没给默认值，BEFORE INSERT里不赋值会直接报错：Field 'Name' doesn't have a default value - PostgreSQL 需显式声明触发器函数返回
NEW，否则字段不会被覆盖；漏写RETURN NEW就等于没生效 - 所有数据库里，触发器都不能调用带事务/网络/临时表的函数——比如别在触发器里查外部 API 填默认名
为什么不能靠 DEFAULT 约束实现多语言默认值
DEFAULT 是静态值，最多支持 CURRENT_TIMESTAMP 或 USER 这类系统函数，没法根据 LanguageID 动态查表。一旦你写 DEFAULT (SELECT DefaultValue FROM LanguageDefaults WHERE LanguageID = 1)，SQL Server 会报错：Subqueries are not allowed in this context。
真正能动态响应的只有触发器或应用层逻辑。但应用层容易遗漏（比如直连数据库的后台脚本），所以触发器是兜底手段——前提是设计时接受它带来的额外执行路径和调试成本。
最容易被忽略的一点：触发器不会自动传播到历史数据。如果已有百万条记录 LanguageID = 2 但 Description 全是 NULL，触发器对它们完全不起作用，得单独跑一次 UPDATE 批量补全。
