A NOT NULL constraint requires a database column to contain a value rather than SQL NULL. It protects required data at the schema boundary, where application errors can otherwise create invalid rows. section 7.3
Inheritance mappings expose an important limitation. With JPA SINGLE_TABLE, subclass properties share one table, so their columns must generally remain nullable: rows for other subclasses have no value for them. Shared superclass properties can still be non-null because every subclass instance uses them. section 7.3
Declaring a required property
A Hibernate mapping can combine Bean Validation with explicit schema generation: @Entity public abstract class BillingDetails { @NotNull @Column(nullable = false) private String owner; } The @NotNull annotation expresses validation, while nullable = false declares the database column constraint. Hibernate ignores Bean Validation's @NotNull when generating the schema, so the explicit @Column setting is needed for schema nullability. section 7.3
A secondary table can restore database enforcement for subclass fields. CreditCard properties move to CREDITCARD, where cardNumber, expMonth, and expYear can be declared NOT NULL; the table uses a primary-key foreign key to the hierarchy table. Polymorphic loading then requires an outer join, whose cost grows with a wide hierarchy. section 7.5
Use NOT NULL constraints as a schema-design decision:
- Prefer SINGLE_TABLE for simple inheritance when performance and straightforward queries outweigh nullable subclass columns. section 7.3
- Consider JOINED when required subclass properties and normalization matter more than avoiding joins; evaluate SQL plans with real data. section 7.7
- Use a secondary table when a SINGLE_TABLE hierarchy needs enforceable NOT NULL constraints for selected subclass data. section 7.5
