SQL primary key, surrogate key, composite keys, foreign keys... and JPA
summary
Practical rules for keys: use a generated surrogate id for stable joins and JPA object identity, but keep composite keys when the relationship itself is the entity (many‑to‑many) or when multi‑tenant or partitioning needs require parent ids in the child row. Demos run on Yugabyte/Postgres-compatible SQL, show composite foreign keys and an association table without extra id, and map composite keys to an embeddable that must be Serializable and implement equals/hashCode. Prefer sequences with allocationSize and DB cache for scale; UUIDs trade predictability for mergeability.
AI-written summary · about
chapters (6)
- 0:00Start
- 11:02Goal of Adding a Surrogate Key
- 23:59Referencing Composite Keys
- 36:47Natural Keys
- 41:10Composite Keys
- 45:40Sequences
related talks
21mImplementing Native Composite Primary Key Support in Rails 7.1
24mImplementing Native Composite Primary Key Support in Rails 7.1
21mImplementing Native Composite Primary Key Support in Rails 7.1
27mData Modeling: Master This Critical Step to Adopting a Distributed Database
46mThe State of Java Relational Persistence
45mHibernate: Mapping Strategies and Their Database Performance Impact
57mUnderstanding Advanced Datatypes in PostgreSQL
42mJPA - Beyond copy-paste