In Spring Boot can I use the same Entity for multiple tables with the same structure

I have multiple tables with different names but they have the same structure. These tables are created on the fly so I don't know in advance their names. Is it possible to have a single Entity to work with all of these Tables? Something similar when you can omit schema so that I can also omit table and specify Table Name on the fly.

@Data
@Entity
@Table(name = "APPLICATIONS", schema = "AIM")
public class Application2 { }

Solution

The Issue with Static Table Mappings in JPA

In typical JPA implementations (such as Hibernate with Spring Boot), an entity’s mapping to a database table is fixed at configuration time. For example:

@Entity
@Table(name = "APPLICATIONS")
public class Application {
    @Id
    private Long id;
    private String name;
    // additional fields, getters, and setters
}

Here, the table name "APPLICATIONS" is explicitly set by the @Table annotation. When the persistence unit is initialized, JPA uses this static definition and does not allow you to substitute a different table name at runtime. Alternative Approaches

Since you cannot change the table mapping on the fly using standard JPA, consider these alternatives:

Using Native Queries or Dynamically Built SQL

One common method is to forgo JPA’s abstraction and create your SQL queries manually. This lets you insert the table name dynamically:

@Service
public class ApplicationService {

    @PersistenceContext
    private EntityManager entityManager;

    public List<Application> findApplications(String dynamicTableName) {
        // Always sanitize 'dynamicTableName' to prevent SQL injection.
        String sql = "SELECT * FROM " + dynamicTableName;
        Query query = entityManager.createNativeQuery(sql, Application.class);
        return query.getResultList();
    }
}

Pros: You can supply any table name at runtime. Cons: You lose JPA benefits like automatic change detection and portability. 2. Using Inheritance with Concrete Subclasses

If you have a known set of tables, you might create a common base class and then extend it with subclasses that each map to a specific table. For instance:

@MappedSuperclass
public abstract class BaseApplication {
    @Id
    private Long id;
    private String name;
    // common properties
}

@Entity
@Table(name = "APPLICATIONS_US")
public class USApplication extends BaseApplication {
    // US-specific fields or methods, if any
}

@Entity
@Table(name = "APPLICATIONS_EU")
public class EUApplication extends BaseApplication {
    // EU-specific fields or methods, if any
}

Pros: Each subclass has a fixed table mapping that JPA recognizes. Cons: This solution only works when the set of table names is known in advance and is not suitable for completely dynamic scenarios. 3. Consolidating Data with a Discriminator or Tenant Identifier

Another approach is to merge all the data into one table and use an extra column to distinguish between different “instances” (for example, tenants or forms). Consider this example:

@Entity
@Table(name = "APPLICATIONS")
public class Application {
    @Id
    private Long id;
    
    @Column(name = "TENANT_ID")
    private String tenantId;
    
    private String name;
    // additional fields, getters, and setters
}

Then, when querying:

public List<Application> findByTenant(String tenantId) {
    String jpql = "SELECT a FROM Application a WHERE a.tenantId = :tenantId";
    return entityManager.createQuery(jpql, Application.class)
                        .setParameter("tenantId", tenantId)
                        .getResultList();
}

Pros: You maintain a single, unified mapping while logically separating data by tenant. Cons: All records are stored in one table, so proper indexing and security controls must be in place. 4. Switching to a JPA Provider with Dynamic Mapping Support

Some JPA providers, such as EclipseLink, offer more flexibility when it comes to defining entity mappings at runtime. If dynamic table names are crucial to your project and you’re open to alternatives, switching from Hibernate might be an option. However, if you’re using Spring Boot (which defaults to Hibernate), there isn’t a standard way to achieve this. Summing Up

Since the table name is embedded in an entity’s metadata in JPA, you cannot have one entity automatically map to multiple tables based on runtime parameters. Your options are:

Native SQL: Build queries on the fly, which sacrifices some of JPA’s conveniences.
Subclassing: Create separate entity classes via inheritance if your table names are predetermined. Unified Table with
Discriminator: Combine all data in one table and use an extra column to segregate the records.
Alternate JPA Provider: Consider using a provider that supports dynamic mappings, though this may require significant changes to your application.

For further details, see discussions (for example, @lajos-arpad’s answer on Stack Overflow) that delve into why JPA’s static mapping model makes runtime-dynamic table names infeasible.