关于Teradata存储过程中ID加减1后关联查询的疑问

刚接触Teradata遇到这种写法确实会有点懵——毕竟常规关联都是直接用等值匹配，加减1看起来像是多此一举，但这种写法绝对不是无意义的，往往是为了适配特定的业务逻辑或数据结构，下面是几种最常见的场景：

1. 处理连续型业务关联的记录 #

很多业务场景里，不同表的ID会被约定成带固定偏移的关联关系：

• 比如订单主表的order_id和订单日志表的log_id，日志表的第一条记录（对应订单创建）的log_id被设定为order_id + 1，用来快速关联订单的初始状态；
• 或者员工层级表中，直属上级的manager_id刚好是下属employee_id - 1，这种设计虽然少见，但部分老系统会用这种方式简化层级关联。

举个直观的代码例子：

SELECT a.order_no, b.log_content
FROM order_main a
INNER JOIN order_status_log b
ON a.order_id + 1 = b.log_id;

这大概率是业务上提前约定了日志ID和订单ID的偏移规则。

2. 兼容历史数据的偏移问题 #

有些老系统在迁移、初始化数据时，可能因为工具限制或人为操作，导致两张关联表的ID存在固定偏移：

• 比如早期从其他数据库迁移到Teradata时，某张表的ID序列起始值比关联表多了1，为了避免修改大量历史数据（修改数据可能涉及业务验证，风险极高），只能用ID±1来做关联兼容。

3. 替代窗口函数实现相邻记录关联 #

在一些较老的存储过程中，开发人员会用ID±1来模拟窗口函数LAG()/LEAD()的功能，获取当前记录的上一条或下一条关联数据：

SELECT curr.record_date, curr.sales_amount, prev.sales_amount AS last_day_sales
FROM daily_sales curr
LEFT JOIN daily_sales prev
ON curr.id - 1 = prev.id;

这种写法用来获取当前记录的前一条数据，相当于LAG(sales_amount) OVER(ORDER BY id)的替代方案，在早年窗口函数支持不完善的场景中很常见。

4. 特殊编码规则的约定 #

部分业务系统会给不同类型的记录设置带偏移的ID规则：

• 比如主表用奇数ID，子表用偶数ID，且子表ID=主表ID+1，既能快速区分记录类型，又能直接建立关联；
• 或者归档表的ID是原表ID-1，用来标记该记录是归档后的副本。

如果想确认具体原因，你可以试试这几个方法：

• 查看两张表的字段注释，看ID字段的生成规则说明；
• 查看存储过程的注释或相关业务文档；
• 抽取一些样本数据，对比两张表的ID值，验证是否存在固定偏移规律。

内容的提问来源于stack exchange，提问作者Mariela