Какие плюсы и минусы синтетического ключа?

Плюсы и минусы синтетических ключей в базах данных

Синтетический ключ (surrogate key) — это искусственно созданный первичный ключ, который не имеет отношения к бизнес-данным. Обычно это просто автоинкрементирующееся число или UUID, которое используется исключительно для идентификации записи.

Что такое синтетический ключ

Сравнение синтетических и естественных ключей:

-- Естественный ключ (натуральный) — основан на бизнес-данных
CREATE TABLE users (
    email VARCHAR(255) PRIMARY KEY,
    name VARCHAR(255),
    created_at TIMESTAMP
);

-- Синтетический ключ — искусственный идентификатор
CREATE TABLE users (
    id BIGINT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    email VARCHAR(255) UNIQUE NOT NULL,
    name VARCHAR(255),
    created_at TIMESTAMP
);

Плюсы синтетических ключей

1. Независимость от бизнес-данных

Основной плюс — ключ не меняется при изменении данных:

-- С синтетическим ключом
CREATE TABLE products (
    id BIGINT PRIMARY KEY,
    sku VARCHAR(50) UNIQUE,
    name VARCHAR(255),
    price DECIMAL(10, 2)
);

INSERT INTO products (id, sku, name, price) 
VALUES (1, 'PROD-001', 'Laptop', 999.99);

-- SKU изменился, но id остался прежним
UPDATE products SET sku = 'LAPTOP-001' WHERE id = 1;
-- Все связи остались целыми!

Если бы SKU был первичным ключом:

-- Естественный ключ (опасно!)
CREATE TABLE products (
    sku VARCHAR(50) PRIMARY KEY,
    name VARCHAR(255),
    price DECIMAL(10, 2)
);

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    product_sku VARCHAR(50),
    quantity INT,
    FOREIGN KEY (product_sku) REFERENCES products(sku)
);

-- Изменение SKU — кошмар!
-- Нужно обновить все заказы!

2. Короче и быстрее в индексах

Целое число занимает меньше памяти, чем строка:

-- Синтетический ключ (8 байт для BIGINT)
SELECT * FROM orders WHERE user_id = 12345;
-- Index lookup быстрый

-- Естественный ключ (переменная длина)
SELECT * FROM orders WHERE user_email = 'user@example.com';
-- Email может быть 50+ символов

Для больших таблиц это существенно:

-- 1 млн записей
-- Синтетический индекс: ~8 Мб (BIGINT)
-- Естественный индекс: ~50+ Мб (Email)

3. Улучшение производительности join'ов

Особенно при соединении многих таблиц:

-- Быстро (целые числа)
SELECT u.name, o.total, p.name
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id
WHERE u.id = 123;

-- Медленнее (строки и составные ключи)
SELECT u.name, o.total, p.name
FROM users u
JOIN orders o ON u.email = o.user_email
JOIN products p ON o.product_sku = p.sku
WHERE u.email = 'user@example.com';

4. Гибкость в добавлении бизнес-требований

Можно переделать структуру без потери целостности:

-- Захотели в продуктах добавить вариантность
-- С синтетическим ключом просто добавляем новую таблицу
CREATE TABLE product_variants (
    id BIGINT PRIMARY KEY,
    product_id BIGINT REFERENCES products(id),
    size VARCHAR(10),
    color VARCHAR(50)
);

-- Все заказы остаются целыми, т.к. они ссылаются на product.id

5. Универсальность

Одна стратегия для всех таблиц:

// Единственный подход
@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String email;
    private String name;
}

@Entity
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    private String sku;
    private String name;
}

6. Безопасность

Осложняет угадывание ID:

// GET /api/users/123 — легко угадать
// GET /api/users/uuid-550e8400-e29b-41d4-a716-446655440000 — сложнее

@RestController
public class UserController {
    @GetMapping("/api/users/{id}")
    public User getUser(@PathVariable UUID id) {
        // Угадать UUID сложнее, чем последовательный номер
        return userService.findById(id);
    }
}

7. Поддержка UUID для микросервисов

Удобно при распределённых системах:

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.UUID)
    private UUID id;
    
    private String email;
}

// UUID генерируется на клиенте
// Не нужна координация с БД
UUID userId = UUID.randomUUID();
User user = new User(userId, "user@example.com");

Минусы синтетических ключей

1. Лишний столбец и памяць

Все записи хранят дополнительный идентификатор:

-- Если естественный ключ уже уникален, синтетический — избыточность
CREATE TABLE countries (
    id BIGINT PRIMARY KEY,      -- Лишний столбец
    code CHAR(2) UNIQUE NOT NULL, -- Мог бы быть первичным ключом
    name VARCHAR(100)
);

INSERT INTO countries (id, code, name) 
VALUES (1, 'US', 'United States');
INSERT INTO countries (id, code, name) 
VALUES (2, 'GB', 'Great Britain');

-- Код уже уникален и осмыслен,
-- зачем нужен дополнительный id?

Для миллионов записей это заметно:

-- 10 млн пользователей, каждый id = 8 байт
-- Синтетический ключ занимает 80 Мб памяти

2. Снижение читаемости

Идентификаторы становятся менее информативными:

-- Читаемо (естественный ключ)
SELECT * FROM countries WHERE code = 'US';
SELECT * FROM countries WHERE code IN ('US', 'GB', 'CA');

-- Менее читаемо (синтетический)
SELECT * FROM countries WHERE id = 1;
-- Что это за 1? Непонятно без справочника

3. Нужен отдельный уникальный индекс

Эсть дополнительные накладные расходы:

CREATE TABLE products (
    id BIGINT PRIMARY KEY,
    sku VARCHAR(50) UNIQUE,      -- Нужен отдельный индекс
    name VARCHAR(255)
);

-- Два индекса вместо одного!
-- Больше памяти, медленнее INSERT/UPDATE

4. Сложность в некоторых сценариях

Если нужно получить ID только что вставленной записи:

// Нужно явно получать сгенерированный ID
@Repository
public class UserRepository {
    public User save(User user) {
        // Нужно обработать сгенерированный ID
        // С естественным ключом было бы проще
        String generatedId = insertUser(user);
        user.setId(generatedId);
        return user;
    }
}

5. Усложнение импорта данных

При импорте из внешних источников:

-- Нужно генерировать или маппировать ID
INSERT INTO users (id, email, name)
SELECT 
    nextval('users_id_seq'),  -- Нужно генерировать
    email,
    name
FROM import_data
WHERE email NOT IN (SELECT email FROM users);

6. Проблемы с кешированием

Кеши часто используют натуральные ключи:

// Какой ключ использовать в кеше?
// Natural key: user:john@example.com
// Synthetic key: user:123456

@Service
public class UserService {
    @Cacheable(value = "users", key = "#email")
    public User findByEmail(String email) {
        // Кеш по email проще
        return userRepository.findByEmail(email);
    }
}

7. Видимость бизнес-смысла

В API натуральный ключ информативнее:

-- Синтетический ключ
GET /api/users/12345
DELETE /api/users/12345

-- Натуральный ключ (или часть URL)
GET /api/users/john@example.com
DELETE /api/users/john@example.com

Комбинированный подход (Best Practice)

Обычно используют оба:

CREATE TABLE users (
    -- Синтетический PK для FK и индексов
    id BIGINT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    
    -- Натуральные ключи
    email VARCHAR(255) UNIQUE NOT NULL,
    username VARCHAR(100) UNIQUE NOT NULL,
    
    -- Данные
    name VARCHAR(255),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE orders (
    id BIGINT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    user_id BIGINT NOT NULL REFERENCES users(id),
    order_number VARCHAR(50) UNIQUE NOT NULL, -- Натуральный ключ
    total DECIMAL(10, 2),
    created_at TIMESTAMP
);

В коде:

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; // Синтетический
    
    @Column(unique = true)
    private String email; // Натуральный
    
    @Column(unique = true)
    private String username; // Натуральный
}

Когда использовать синтетические ключи

Используй синтетические ключи для:

• Главных таблиц (users, products, orders)
• Таблиц с естественными ключами большого размера
• Таблиц с частыми обновлениями FK
• Когда FK используются часто (join'ы, индексы)

Используй натуральные ключи для:

• Справочников (страны, валюты, штаты)
• Сущностей с очевидным уникальным идентификатором
• Когда натуральный ключ всегда стабилен

Выводы

Синтетические ключи — это стандартный выбор в современных базах данных, потому что они обеспечивают гибкость, производительность и независимость от бизнес-данных. Основной минус — избыточность памяти, но это часто приемлемая цена за удобство. Лучший подход — использовать синтетический PK для внутренних связей и натуральные уникальные индексы для бизнес-идентификации. Это дает лучшее из обоих миров.