# 旧规则绑定表下线观察与删表草案

## 当前策略

- 新主链路：`leaudit_rule_group_bindings`
- 旧兼容表：`leaudit_rule_type_bindings`
- 当前仅保留 `UpdateBinding / DeleteBinding` 对历史 `BindingId` 的 fallback

## 已完成

- 文档类型保存不再双写旧表
- `CreateBinding` 不再 fallback 写旧表
- 规则绑定主读链路优先读取新分组绑定

## 观察期要看什么

### 1. 后端日志

当前已经在以下场景增加明确日志：

- `rule binding legacy fallback hit on update`
- `rule binding legacy fallback hit on delete`

如果观察期内不再出现以上日志，说明已经基本没有历史旧 `BindingId` 命中。

### 2. 数据检查

执行：

```bash
psql ... -f scripts/precheck_drop_legacy_rule_type_bindings.sql
```

重点看：

- `doc_types_legacy_only = 0`
- 新链路绑定明细完整
- 旧表活动绑定仅剩历史冗余数据

## 建议收口顺序

1. 保持现状进入观察期
2. 连续一段时间无 fallback 日志
3. 删除 `UpdateBinding / DeleteBinding` 的旧表 fallback
4. 再执行删表 SQL

## 删表前条件

- 前端主链路全部走评查点分组绑定接口
- 不再有外部脚本调用旧 `/api/rule-sets/bindings/{bindingId}` 历史 ID
- 观察期日志为 0
- `doc_types_legacy_only = 0`

## 删表 SQL 草案

```sql
BEGIN;

DROP TABLE IF EXISTS leaudit_rule_type_bindings;

COMMIT;
```

## 回滚草案

如果只是删 fallback 代码但还没删表，直接回滚代码即可。

如果已经删表，必须依赖：

- 事先数据库备份
- 或按历史 DDL 重建表结构后再回灌数据

因此删表动作必须放在数据库备份之后执行。