Spring Boot JPA中@Entity是否会生成表？多场景技术疑问

背景 #

我是Spring Boot API开发新手，项目同时连接Oracle和PostgreSQL数据库：Oracle有现成表，需要从中多表取数返回响应；PostgreSQL用来存用户数据和其他不需要进Oracle的数据，目前用原生查询实现。

已经创建了Account实体，把一个非主键但全局唯一的字段标记为@Id：

@Entity
@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class Account {
  @Id
  private String sampleProperty1;
  private String sampleProperty2;
  private String sampleProperty3;
  private String sampleProperty4;
  private String sampleProperty5;
}

同时定义了仓库接口：

public interface IAccountRepository extends JpaRepository<Account, String> {
  @Query(value = "SELECT * FROM TABLE(SAMPLE_PACKAGE.SAMPLE_FUNC_GETACCOUNTS(?1))", nativeQuery = true)
  List<Account> getAllAccountsByClientNumber(String clientNumber);
}

目前已经成功取数并通过JPA自动映射到实体，这个实体只用来映射Oracle的数据并返回。

备注：知道可以基于Oracle现有表创建实体，但未来API会断开Oracle连接；试过用projections，但需要创建响应模型手动映射，而且单元测试流程太繁琐。

问题 #

• 这种方式会不会在Oracle里创建ACCOUNT表？目前没发现，但担心生产环境自动创建，要是有这个风险怎么阻止？
• 这种方式用来做Oracle的其他操作（比如获取交易历史、创建交易、更新账户数据）合适吗？有没有更优方案？
• 在Spring Boot里创建没有对应数据库表的实体有哪些弊端？

解答 #

关于问题1 #

当前方式不会自动创建ACCOUNT表，但要彻底杜绝生产环境的风险，得从配置和实体注解两方面处理：

1. 全局配置控制：在Spring Boot配置文件中，针对Oracle数据源设置spring.jpa.hibernate.ddl-auto=none，这会直接禁用Hibernate的自动DDL生成功能，从根源上阻止表创建。如果是多数据源配置，一定要确保这个配置只作用于Oracle的EntityManagerFactory，别影响PostgreSQL的配置。
2. 实体层面补充：可以给Account实体加上@Immutable注解，标记它为不可变实体，让JPA明确知道这个实体只用于查询结果映射，不会涉及写操作；另外也可以通过@Table(name = "DUMMY_ACCOUNT")指定一个不存在的表名，进一步避免Hibernate误操作。

关于问题2 #

这种方式用于**只读操作（比如获取交易历史）是可行的，但用于写操作（创建交易、更新账户）**并不合适，具体分析和优化方案如下：

• 写操作不合适的原因：你的Account实体没有对应Oracle的实际表，执行save/update/delete这类JPA写操作时，会因为找不到表直接报错；就算用原生写语句，也失去了JPA的ORM优势，和直接用JDBC没区别，反而多了一层不必要的实体映射。
• 更优方案：
  • 只读场景：可以继续用当前原生查询映射实体的方式，或者改用@SqlResultSetMapping配合@NamedNativeQuery来更清晰地定义结果映射逻辑，避免@Id标记非主键字段带来的语义误解。
  • 写操作场景：
    • 如果必须用JPA操作Oracle，建议针对实际存在的Oracle表创建对应的实体，哪怕未来会断开Oracle连接，当前阶段能保证写操作的正确性，后续迁移时再替换这部分逻辑即可。
    • 直接用JDBC Template或者MyBatis执行Oracle的写操作，不需要依赖JPA实体，更灵活，也避免了不存在的实体带来的混淆。

关于问题3 #

创建没有对应数据库表的@Entity实体，主要有这些弊端：

• 语义混淆：@Entity注解的本意是标记对应数据库表的持久化类，其他开发人员看到会默认认为存在对应的表，增加理解成本和维护风险。
• JPA特性受限：没法使用JPA自带的CRUD操作（save、update、delete等），这些操作依赖实体和表的映射关系，执行时会直接报错找不到表。
• 配置风险：如果不小心把ddl-auto设置成create/update，Hibernate会尝试创建对应的表，可能污染数据库或者引发异常。
• 测试麻烦：单元测试时，Spring Data JPA的测试框架会默认基于实体创建测试表，导致测试失败，还得额外配置规避。
• 潜在逻辑异常：@Id标记的不是数据库表的主键，可能会导致JPA内部的缓存、脏数据检查等逻辑出现异常，虽然当前只读场景下可能没问题，但长期维护容易出问题。

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