Schema reviews get harder as the number of tables grows.
Reading a few CREATE TABLE statements is manageable, but once there are many relationships, it becomes difficult to keep the whole structure in your head.

Generating an ER diagram from SQL DDL gives you a quick overview before digging into constraints and indexes.

Example

CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL
);

CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  user_id INTEGER NOT NULL,
  total INTEGER NOT NULL,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

The relationship can be represented as Mermaid ER syntax.

erDiagram
  users ||--o{ orders : has

This makes it easier to see which tables are central and which ones depend on others.

What to check during review

  • Foreign keys point to the expected parent tables
  • Join tables are named clearly
  • One-to-many and many-to-many relationships are easy to read
  • Dependencies are not stronger than necessary
  • Delete behavior and indexes are reviewed separately in the DDL

An ER diagram is not a replacement for the DDL.
It is a map that helps reviewers know where to look.

Why Mermaid helps

Mermaid can be stored in README files, design notes, or pull requests as text.
That makes changes easier to review than a static image.