The Domain Model

An employee enters a building every day using an access card. A visitor might enter the same building using a temporary credential.

Both people have a name, an identity, and authentication information. However, they do not have the same business data. An employee has an employee number and company email. A visitor has a visitor number and an external company.

Java represents this naturally with inheritance:

AccessUser
├── Employee
└── Visitor

But relational databases do not understand classes, inheritance, or subtypes. They understand tables, columns, primary keys, foreign keys, and joins.

This creates an important question:

How does Hibernate store one Java subtype when part of its data comes from a parent class and the rest comes from the subtype?

JPA’s JOINED inheritance strategy answers this.

This note focuses exclusively on InheritanceType.JOINED. JPA also supports SINGLE_TABLE and TABLE_PER_CLASS, while @MappedSuperclass is commonly discussed as another inheritance-mapping approach. We will leave those alternatives for separate articles.

Consider a simplified access-control system.

Every person who receives access credentials is represented as an AccessUser. Employees and Visitors are specialized types of access users.

The parent class contains information shared by every subtype:

public abstract class AccessUser {

    protected Long id;
    protected String firstName;
    protected String lastName;
    protected String credential;
}

An employee adds employee-specific information:

public class Employee extends AccessUser {

    private String employeeId;
    private String email;
}

A visitor adds visitor-specific information:

public class Visitor extends AccessUser {

    private String visitorId;
    private String company;
}

The entity hierarchy looks like this:

This hierarchy represents a genuine subtype relationship:

An Employee is an AccessUser.
A Visitor is an AccessUser.

The next challenge is mapping that object model to relational tables.

Mapping the Hierarchy with JOINED

The inheritance strategy is declared on the root entity:

@Entity
@Table(name = "access_users")
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class AccessUser {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    protected Long id;

    @Column(nullable = false)
    protected String firstName;

    @Column(nullable = false)
    protected String lastName;

    protected String credential;

    protected AccessUser() {
    }
}

The key annotation is:

@Inheritance(strategy = InheritanceType.JOINED)

It tells the JPA provider to:

1. Use one table for the root entity.

2. Use a separate table for each managed subtype.

3. Store common fields in the root table.

4. Store subtype-specific fields in the subtype table.

5. Connect the parent and subtype rows using the same primary key.

Declare the strategy only on the root of the hierarchy. It does not need to be repeated on every subtype.

The concrete subtypes still need to be JPA entities:

@Entity
@Table(name = "employees")
public class Employee extends AccessUser {

    @Column(nullable = false, unique = true)
    private String employeeId;

    @Column(nullable = false)
    private String email;

    protected Employee() {
    }
}

@Entity
@Table(name = "visitors")
public class Visitor extends AccessUser {

    @Column(nullable = false, unique = true)
    private String visitorId;

    private String company;

    protected Visitor() {
    }
}

Each subtype uses extends AccessUser for Java inheritance and @Entity for JPA persistence.

The Resulting Database Tables

The mapping produces one parent table and one table for each subtype:

A simplified PostgreSQL schema could look like this:

CREATE TABLE access_users (
    id          BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    first_name  TEXT NOT NULL,
    last_name   TEXT NOT NULL,
    credential  TEXT
);

CREATE TABLE employees (
    id           BIGINT PRIMARY KEY,
    employee_id  TEXT NOT NULL UNIQUE,
    email        TEXT NOT NULL,

    CONSTRAINT fk_employees_access_user
        FOREIGN KEY (id) REFERENCES access_users (id)
);

CREATE TABLE visitors (
    id               BIGINT PRIMARY KEY,
    visitor_id       TEXT NOT NULL UNIQUE,
    company          TEXT,

    CONSTRAINT fk_visitors_access_user
        FOREIGN KEY (id) REFERENCES access_users (id)
);

The most important part of this structure is the subtype ID:

employees.id → access_users.id
visitors.id  → access_users.id

The subtype table’s id is both:

• its primary key;

• a foreign key to access_user.id

Suppose both tables contain a row with ID 42:

access_users
────────────────────────────────────────────
id    first_name    last_name    credential
42    Ethan         Zay          CARD-1007

visitors
────────────────────────────────────
id    visitor_id    company
42    V99881        Example Ltd

These are not two independent business objects. Together, they represent one Visitor:

access_users row 42
        +
visitors row 42
        ↓
one Visitor entity

This is the central idea behind JOINED inheritance.

What Happens When Hibernate Saves a Visitor?

Consider the following object:

Visitor visitor = new Visitor();
visitor.setFirstName("Ethan");
visitor.setLastName("Zay");
visitor.setCredential("CARD-1007");
visitor.setVisitorId("V99881");
visitor.setCompany("Example Ltd");

visitorRepository.save(visitor);

Hibernate needs to persist both the inherited state and the visitor-specific state.

It first inserts the common fields into access_users:

INSERT INTO access_users (
    first_name,
    last_name,
    credential
)
VALUES (
    'Ethan',
    'Zay',
    'CARD-1007'
)
RETURNING id;

Assume that the database generates ID 42. Hibernate then uses that ID when inserting the subtype fields:

INSERT INTO visitors (
    id,
    visitor_id,
    company
)
VALUES (
    42,
    'V99881',
    'Example Ltd'
);

One Java object therefore produces two database rows:

Visitor object
    │
    ├── common state ────────> access_users row 42
    │
    └── visitor state ───────> visitors row 42

Both inserts normally execute within the same transaction. If one insert fails, the transaction should roll back instead of leaving an incomplete entity behind.

What Happens When Hibernate Loads a Visitor?

When the application loads visitor 42, Hibernate needs information from both tables.

The exact generated SQL depends on the Hibernate version and database dialect, but its logical form is:

SELECT
    au.id,
    au.first_name,
    au.last_name,
    au.credential,
    v.visitor_id,
    v.company
FROM access_users au
JOIN visitors v ON v.id = au.id
WHERE au.id = 42;

Hibernate combines the columns into one Java object:

Visitor {
    id = 42,
    firstName = "Ethan",
    lastName = "Zay",
    credential = "CARD-1007",
    visitorId = "V99881",
    company = "Example Ltd"
}

The application works with one object even though its state is stored across two tables.

This join is both the mechanism and the principal cost of JOINED inheritance. Every subtype read requires Hibernate to join the subtype table with its parent table.

Because the root is also an entity, a query against AccessUser can return both Employee and Visitor instances. Hibernate may need additional joins to determine the concrete subtype, so parent-level queries become more expensive as a hierarchy grows.

Benefits of JOINED Inheritance

The JOINED strategy provides several useful properties.

Normalized tables

Common fields are stored once in the parent table instead of being repeated in every subtype table.

Strong subtype constraints

Subtype-specific columns can have appropriate database constraints:

visitor_id     TEXT NOT NULL
employee_id    TEXT NOT NULL UNIQUE

This is harder to enforce when unrelated subtype columns share one large table.

Shared identity

Every employee and visitor has a common AccessUser identity. Other parts of the system can reference that shared identity when the domain requires it.

Polymorphic entity model

Application code can operate on the parent type when it does not need subtype-specific behavior.

The Jakarta Persistence specification describes JOINED as a well-normalized strategy with support for polymorphic relationships.

Trade-Offs to Consider

JOINED is not automatically the best strategy for every hierarchy.

Additional joins

Loading a subtype requires at least one join with its parent table.

Queries across the hierarchy

Queries against the parent entity may need to inspect several subtype tables. A hierarchy with many subtypes can generate large SQL statements.

Multi-table writes

Creating or deleting a subtype affects more than one table. Updating fields can also target different tables:

Changing firstName → UPDATE access_users
Changing company   → UPDATE visitors

More complex schema changes

The database must maintain parent-child foreign-key integrity. Migrations and manual data operations need to respect that relationship.

The Java model may look simple, but developers should still inspect the SQL generated for important production queries.

Common implementation mistakes

Missing @Entity on a subtype

This is incomplete:

@Table(name = "visitors")
public class Visitor extends AccessUser {
}

@Table specifies a table mapping, but it does not register the class as an entity.

The correct mapping is:

@Entity
@Table(name = "visitors")
public class Visitor extends AccessUser {
}

Declaring a Separate ID in the subtype

The subtype should inherit the parent ID. It should not introduce an unrelated primary key:

@Entity
public class Visitor extends AccessUser {

    // Do not declare another @Id here.
}

The shared ID is what connects the parent and subtype rows.

Using inheritance only to reuse fields

Two entities sharing createdAt and updatedAt does not necessarily mean they belong to the same entity hierarchy.

Use inheritance when the subtype truly represents the parent concept:

Visitor is an AccessUser → valid subtype

When JOINED is a good fit?

Consider JOINED when:

• the classes have a genuine “is-a” relationship;

• the subtypes share meaningful business identity;

• normalized tables are important;

• subtype-specific constraints matter;

• polymorphic behavior is required;

• the hierarchy contains a controlled number of subtypes;

• the cost of joins is acceptable.

Reconsider it when:

• the classes only share technical fields;

• the hierarchy contains many levels or subtypes;

• most queries process the entire hierarchy at high volume;

• query latency is more important than normalization;

• the database structure would be simpler without entity inheritance.

Key takeaway

JPA JOINED inheritance maps one Java entity across a parent table and a subtype table.

The parent table stores shared state. The subtype table stores specialized state. The same primary key connects both rows:

AccessUser row + Employee row = one Employee entity
AccessUser row + Visitor row = one Visitor entity

This produces a normalized schema and a clean Java hierarchy, but it also introduces joins and multi-table persistence operations.

Before choosing JOINED, draw three things:

1. The Java class hierarchy.

2. The resulting database tables.

3. The SQL required to save and load a subtype.

If those three views accurately represent the business domain and the query cost is acceptable JOINED can be a clear and production-ready inheritance strategy.

References

• Jakarta Persistence: InheritanceType

• Hibernate ORM User Guide: Inheritance