DDL / СхемаНачальный

PRIMARY KEY

Уникальный идентификатор строки. Автоматически создаёт уникальный индекс, не допускает NULL.

Синтаксис

id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY
-- или
PRIMARY KEY (col1, col2)  -- составной

Объяснение

PRIMARY KEY = UNIQUE + NOT NULL + автоматический индекс. На таблицу — только один. Рекомендации для PostgreSQL: - BIGINT GENERATED ALWAYS AS IDENTITY — современный стандарт - UUID — если нужна глобальная уникальность, но медленнее из-за случайности (UUID v7 лучше) - Суррогатный ключ (id) лучше натурального (email) — email может измениться

Пример

-- Современный вариант
CREATE TABLE products (
  id    BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name  TEXT NOT NULL
);

-- Составной ПК
CREATE TABLE order_items (
  order_id   BIGINT REFERENCES orders(id),
  product_id BIGINT REFERENCES products(id),
  PRIMARY KEY (order_id, product_id)
);

Связанные термины

CREATE TABLEСоздаёт новую таблицу с определёнными колонками и ограничениями.FOREIGN KEYОграничение, связывающее колонку с первичным ключом другой таблицы. Обеспечивает ссылочную целостность.INDEX (индекс)Структура данных, ускоряющая поиск строк по значению колонки.

Анекдоты по теме

Как узнать, что разработчик только начал учить SQL? Он пишет SELECT * FROM всё WHERE что-нибудь = 'что-то'

— Почему timestamp without time zone опасен? — Хранит время без информации о часовом поясе. — Проблема? — Сервер в UTC, приложение в Moscow, пользователь в Vladivostok. База хранит 10:00 — но это 10:00 где? — Решение? — TIMESTAMPTZ (timestamp with time zone). Хранит UTC, отображает в нужной зоне.

Разработчик смотрит на код коллеги: SELECT * FROM a, b WHERE a.id = b.a_id — Это что, неявный JOIN? — Синтаксис из 1992 года. — Оно работает? — Да. Но использовать — моветон.

Все анекдоты →

Потренироваться →← Все термины