Category Archives: Без рубрики

What the relational model guarantees The relational model defines what states of data are valid. These guarantees are logical, not performance-related. 1️⃣ Set-based data (no duplicates by default) Relations are sets, not lists Rows have no inherent order Duplicates are … Continue reading →

High-level idea (keep this in mind) In PostgreSQL, you define the logical schema explicitly,and PostgreSQL derives and manages the physical schema implicitly, with optional tuning knobs. You declare intent → Postgres decides storage. 1️⃣ Logical schema in PostgreSQL (what you … Continue reading →

Logical schema vs Physical schema Logical schema describes what the data model is.Physical schema describes how it is stored and accessed. That sentence alone already scores points. 1️⃣ Logical schema What it is The logical schema defines: Entities and attributes … Continue reading →

Why are foreign keys needed (beyond JOINs)? Foreign keys are about data correctness and lifecycle guarantees — not query syntax. JOINs are just a query feature.Foreign keys are integrity constraints. What a foreign key actually guarantees A foreign key enforces … Continue reading →

Why composite keys break equals() / hashCode() in ORM ORMs rely on equals() / hashCode() to track entity identity.Composite keys make identity mutable, incomplete, or unstable during an entity’s lifecycle. That’s the root problem. First: how ORM uses equals() / … Continue reading →

Why ORMs (JPA / Hibernate) struggle with composite primary keys First: what ORM expects An ORM assumes: One column = one identity Identity is simple, immutable, comparable Identity is used for: Persistence context (1st-level cache) Equality checks Lazy loading Proxies … Continue reading →

Short answer (interview-ready) Using a composite primary key in a many-to-many table is often problematic because it tightly couples identity to business columns, complicates foreign keys, hurts ORM usability, and makes future schema evolution harder — even though it looks … Continue reading →

Pros of having surrogate key + unique business fields This pattern separates technical identity from business rules — which is the core reason it scales in real systems. 1️⃣ Stable identity + flexible business rules Why it matters Business data … Continue reading →

Short answer (interview-ready) Surrogate keys provide technical identity, but natural keys enforce business correctness.Without enforcing natural keys, a relational database cannot protect the domain from invalid or duplicate business data. That’s the essence. Now let’s break it down. What surrogate … Continue reading →

What is a Surrogate Key? Definition A surrogate key is an artificial, system-generated identifier used as a primary key that has no business meaning. Typical forms: Auto-increment integer (SERIAL, IDENTITY) Sequence-based BIGINT UUID Example: Why is it called surrogate? Surrogate … Continue reading →