Database Design Book

ID design and primary keys, pt. 2

Sun, 06 Sep 2026 20:00:00 +0100

Author: Alexey Makhotkin squadette@gmail.com, (~2200 words)

In the first part we introduced a strict separation between logical and physical aspects around IDs and primary keys.

We discussed the logical concepts of external IDs and anchor IDs, and the physical concept of a primary key.

There are four main data elements: anchors, attributes, links, and secondary data. Every database is modeled using a combination of those elements. Elements map to physical tables, and each physical table needs a primary key.

ID design and primary keys, pt. 1

Fri, 21 Aug 2026 20:00:00 +0100

Author: Alexey Makhotkin squadette@gmail.com, (~2300 words)

This is the first part of a systematic discussion of primary keys in database design. As usual, we present the material in a way that deviates from the traditional approach.

This is basically a bonus chapter from the “Database Design Book”. The goal of this text is to teach you how to design your primary keys based on business requirements.

In part 1, we begin at the logical level.

ERD diagrams, pt. II: physical diagrams

Mon, 25 Aug 2025 22:30:00 +0100

Author: Alexey Makhotkin squadette@gmail.com.

In the first part we’ve designed a logical ERD diagram based on the structured logical model. We built the structured logical model from the free-text business requirements.

What if we need to draw a physical ERD diagram for the same task? It turns out that we’ve already done maybe 80% of the work, and we can reuse the structured logical model verbatim. We’ll just use a different graphical notation.

ERD diagrams, pt. I: many-to-many relationships

Fri, 25 Jul 2025 22:30:00 +0100

Author: Alexey Makhotkin squadette@gmail.com.

I started writing a long post on how to design correct ERD diagrams based on the approach from the “Database Design Book”, but the text got a bit unwieldy. So I’m going to regroup and focus on one part: many-to-many relationships (“M:N links” in book terms).

Suppose that you need to build an ERD diagram based on some sort of real-world or teaching task. How do you make sure that your ERD diagram is correct?

Systematic design of multi-join GROUP BY queries

Thu, 22 May 2025 22:30:00 +0100

Author: Alexey Makhotkin squadette@gmail.com, ~5400 words.

This is the first public revision of this text. Early readers have shared encouraging feedback, but I’m sure there’s still room for improvement. I’m releasing it now to gather broader input from a wider audience.

Update (2025-06-08): I wrote a prequel to this text: “Multi-join queries design: investigation”. https://minimalmodeling.substack.com/p/multi-join-queries-design-investigation, another 3400 words.

Update (2026-01-25): Here is another prequel: “A modern guide to SQL JOINs” (~8800 words). This one builds the foundation to systematically build queries based on JOINs. https://kb.databasedesignbook.com/posts/sql-joins/.

Historized attributes: systematic table design

Sat, 09 Nov 2024 14:00:00 +0100

Author: Alexey Makhotkin squadette@gmail.com.

(Word count: 3200).

A common problem in business-oriented database design: keeping the history of values of a certain data attribute. For example, we may want to track the price of various goods, as they change with time. Many other tasks could be reduced to this problem: for example, when people change their address in the government database, we may want to keep track of previous addresses.

TL;DR: A solution is presented below, in the “Final SQL schema” section.

Many yes/no attributes: table design study

Thu, 20 Jun 2024 00:13:00 +0100

Author: Alexey Makhotkin squadette@gmail.com.

I wanted to demonstrate the relationship between the logical model and a physical model. We’re going to design a commonly seen use case: many yes/no attributes of a single anchor (in our case, Restaurant). Then we’ll discuss how the physical tables would be designed. We’ll see that sometimes physical design strategy changes as the system becomes more mature. At the same time, logical design elements never change if the business requirement is still relevant.