Great question! Let’s break this down for your Spring Boot scenario, covering your core questions and practical alternatives.

Can you create tables and run queries without defining entities or CrudRepositories? #

Yes, absolutely—but it’s not the standard Spring Data JPA workflow. Spring Data JPA is built around entity mappings and repository abstractions, but you can bypass this using lower-level database access tools:

• Use JdbcTemplate: This is Spring’s lightweight JDBC wrapper that lets you execute raw SQL directly. You can fetch the target table name from your BusinessType entity, then run DDL (like CREATE TABLE) and DML (like SELECT) statements dynamically.
• Use EntityManager with native SQL: You can inject EntityManager and call createNativeQuery() to run custom SQL, which also works without predefined entities.

Here’s a quick example using JdbcTemplate:

@Autowired
private JdbcTemplate jdbcTemplate;
@Autowired
private BusinessTypeRepository businessTypeRepo;

// Create a dynamic table based on BusinessType
public void createBusinessSpecificTable(String businessTypeName) {
    BusinessType coffeeShopType = businessTypeRepo.findByName(businessTypeName)
            .orElseThrow(() -> new RuntimeException("Business type not found"));
    String targetTable = coffeeShopType.getTableName();

    // Raw SQL to create the table (adjust fields to your needs)
    String createTableSql = String.format("""
            CREATE TABLE IF NOT EXISTS %s (
                id BIGINT AUTO_INCREMENT PRIMARY KEY,
                business_id BIGINT NOT NULL,
                shop_name VARCHAR(255) NOT NULL,
                opening_hours VARCHAR(100),
                FOREIGN KEY (business_id) REFERENCES business(id)
            )""", targetTable);

    jdbcTemplate.execute(createTableSql);
}

// Query the dynamic table
public List<Map<String, Object>> fetchCoffeeshopData(Long businessId, String businessTypeName) {
    BusinessType type = businessTypeRepo.findByName(businessTypeName)
            .orElseThrow(() -> new RuntimeException("Business type not found"));
    String querySql = String.format("SELECT * FROM %s WHERE business_id = ?", type.getTableName());
    return jdbcTemplate.queryForList(querySql, businessId);
}

The catch here is that results come back as Map<String, Object> (or you can use a custom RowMapper), so you lose the type safety of JPA entities.

Alternative Approaches If You Want More Structure #

If raw SQL feels too low-level, consider these options:

1. Dynamic Entity Generation #

You can generate entity classes at runtime using libraries like ByteBuddy or CGLib, then dynamically register them with Spring’s application context and create proxy repositories. This lets you use Spring Data JPA’s features (like query methods) without predefining entities. However, this is complex and requires handling class loading and bean registration—best for advanced use cases.

2. Spring Data JDBC #

Spring Data JDBC is a lighter alternative to JPA that doesn’t require strict entity mappings (though it’s common to use them). It supports dynamic SQL and works well with Map results or custom row mappers, making it easier to handle dynamic tables than full JPA.

3. MyBatis #

MyBatis is a SQL-mapping framework that excels at dynamic SQL. You can define flexible queries in XML or annotations, dynamically swapping table names and fields without strict entity bindings. It’s a great middle ground between raw JDBC and JPA.

4. JPA Inheritance Strategies (Adjust Your Schema) #

If you can tweak your database schema instead of using dynamic tables, JPA’s built-in inheritance handles base + specific types natively:

• Single Table Inheritance: All business types share one table, with a discriminator column (e.g., business_type) to distinguish between coffeeshops, restaurants, etc. Simple and fast, but can lead to unused columns if types have very different fields.
• Joined Inheritance: A base business table, plus separate tables for each specific type (e.g., coffeeshop) linked via foreign key. Clean schema, but requires joins for queries.
• Table Per Class: Each type (including the base) has its own table with all fields. Avoid this if possible—queries across types require UNION operations, which are slow.

Handling Base + Specific Types in Typical Spring Data JPA Apps #

The standard approach here is inheritance with discriminators or composition:

Inheritance Example #

Define a base Business entity with a discriminator:

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
@DiscriminatorColumn(name = "business_type")
public abstract class Business {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    // common fields
}

@Entity
@DiscriminatorValue("COFFEESHOP")
public class Coffeeshop extends Business {
    private String shopName;
    private String openingHours;
    // coffeeshop-specific fields
}

Then you can use a BusinessRepository to query all businesses, or create a CoffeeshopRepository for type-specific queries.

Composition Example #

If inheritance doesn’t fit, use composition: have a base Business entity that references a BusinessDetails entity, with BusinessDetails using inheritance to handle specific types. This keeps your base business logic separate from type-specific data.

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