Hibernate 实体（@Entity）必须对应数据库中的物理表或视图，无法直接基于存储过程或标量函数结果定义；若需映射函数返回的复杂结构，应使用无 @Entity 注解的 POJO 配合 @Procedure 或原生查询实现。
hibernate 实体（`@entity`）必须对应数据库中的物理表或视图，无法直接基于存储过程或标量函数结果定义；若需映射函数返回的复杂结构，应使用无 `@entity` 注解的 pojo 配合 `@procedure` 或原生查询实现。
在 Hibernate 6 + Spring Boot 3 环境中，一个常见误区是试图将数据库函数（如 PostgreSQL 的 my_function(param1 TEXT, param2 INT) 或 Oracle/SQL Server 的表值函数）的结果强行绑定到 @Entity 类上。正如报错 Schema-validation: missing table [MyEntity] 所揭示的：Hibernate 的 @Entity 核心契约要求其必须映射到一个可被 DDL 管理的持久化单元——即真实存在的表或视图。函数本身不构成 Schema 对象，因此 @Entity + @NamedStoredProcedureQuery 组合在此场景下本质不适用，无论是否添加 @SqlResultSetMapping 或 resultClasses，框架仍会尝试校验对应表结构，导致启动失败。
✅ 正确做法：放弃 @Entity，改用轻量级 POJO + Repository 层声明式调用
推荐使用 Spring Data JPA 提供的 @Procedure 注解（位于 org.springframework.data.jpa.repository 包），它专为调用存储过程/函数设计，且天然支持结果映射至非实体类：
// ✅ 普通 POJO（无 @Entity、无 @Table）
public class Employee {
private Integer id;
private String name;
private Integer age;
private BigDecimal salary;
// 构造函数（必须匹配函数返回列顺序与类型，或配合 @SqlResultSetMapping）
public Employee(Integer id, String name, Integer age, BigDecimal salary) {
this.id = id;
this.name = name;
this.age = age;
this.salary = salary;
}
// getters & setters...
}// ✅ 在 JpaRepository 中声明调用
@Repository
public interface EmployeeRepository extends JpaRepository<Employee, Integer> {
@Procedure(name = "get_employee_data") // 对应函数名（注意：非 procedureName！）
Employee getEmployeeData(@Param("p_employee_id") Integer employeeId);
// 若函数返回多行，可返回 List<Employee>
@Procedure(name = "get_employees_by_dept")
List<Employee> findEmployeesByDepartment(@Param("dept_code") String deptCode);
}⚠️ 注意事项：
- 函数需在数据库中注册为“可调用”对象：PostgreSQL 需定义为 RETURNS TABLE(...) 或 RETURNS SETOF ...；SQL Server 需为 TABLE 返回值函数；Oracle 需为 PIPELINED TABLE FUNCTION。纯 RETURNS INTEGER/VARCHAR 的标量函数不适用此方式。
- 参数名需严格匹配数据库函数定义：@Param("p_employee_id") 中的字符串必须与函数声明中的参数名一致（大小写敏感性依数据库而定）。
- 若字段名/顺序不匹配，或需自定义映射逻辑，可搭配 @SqlResultSetMapping + @ConstructorResult 使用，但此时映射目标类仍不可加 @Entity，且需在 @Procedure 所在 Repository 接口上通过 @Query + nativeQuery = true 手动指定 SQL 调用（例如 SELECT * FROM get_employee_data(?1)）。
- 避免 @Subselect 黑盒方案：您当前使用的 @Subselect + @Filter + Interceptor 方式不仅难以维护，还绕过了 Hibernate 的一级/二级缓存与变更跟踪机制，违背 ORM 设计初衷。
? 总结：当数据源是数据库函数而非表时，请切换思维——这不是“实体建模问题”，而是“结果集消费问题”。使用 POJO + @Procedure 是 Spring Data JPA 官方支持、类型安全、可测试且符合分层架构的最佳实践。既消除了启动校验异常，又保持了代码清晰性与可维护性。
