Может ли быть одно значение и первичным, и внешним ключом?

Первичный и внешний ключ в одном поле: да, может быть

Короткий ответ: Да, абсолютно. Одно и то же поле может быть одновременно первичным ключом и внешним ключом. Это очень распространённый паттерн в проектировании баз данных.

Определения

Сначала вспомним основные понятия:

Первичный ключ (Primary Key)

• Уникально идентифицирует каждую запись в таблице
• Не может быть NULL
• В таблице может быть только один
• Пример: user_id в таблице users

Внешний ключ (Foreign Key)

• Ссылается на первичный ключ другой таблицы
• Обеспечивает связь между таблицами
• Может быть NULL (если связь опциональна)
• Может быть несколько внешних ключей в одной таблице
• Пример: user_id в таблице orders ссылается на user_id из таблицы users

Практические примеры

Пример 1: Один-к-одному связь

Сценарий: каждый пользователь может иметь одну полную информацию профиля.

-- Таблица users
CREATE TABLE users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

-- Таблица user_profiles
CREATE TABLE user_profiles (
    user_id INT PRIMARY KEY,  -- первичный ключ
    user_id INT FOREIGN KEY REFERENCES users(user_id),  -- внешний ключ на ту же колонку
    bio VARCHAR(500),
    avatar_url VARCHAR(255)
);

Объяснение:

• user_id в таблице user_profiles — это первичный ключ (уникальный идентификатор профиля)
• Одновременно это внешний ключ (ссылается на users.user_id)
• Связь один-к-одному: каждому пользователю соответствует ровно один профиль
• Если удалить пользователя, его профиль тоже удалится (ON DELETE CASCADE)

Пример 2: Таблица-справочник с иерархией

Сценарий: категории товаров, где есть основные категории и подкатегории.

CREATE TABLE categories (
    category_id INT PRIMARY KEY,
    name VARCHAR(100),
    parent_category_id INT FOREIGN KEY REFERENCES categories(category_id)
);

Объяснение:

• category_id — первичный ключ
• parent_category_id — внешний ключ на ту же таблицу (self-referencing)
• Позволяет создавать иерархию: "Электроника" → "Смартфоны" → "iPhone"
• Каждая категория может иметь родительскую категорию (опционально)

Пример 3: История изменений

Сценарий: нужно хранить версии документов, где каждая версия связана с предыдущей.

CREATE TABLE documents (
    document_id INT PRIMARY KEY,
    content TEXT,
    created_at TIMESTAMP
);

CREATE TABLE document_versions (
    version_id INT PRIMARY KEY,
    document_id INT,
    content TEXT,
    previous_version_id INT FOREIGN KEY REFERENCES document_versions(version_id),
    created_at TIMESTAMP
);

Объяснение:

• version_id — первичный ключ
• previous_version_id — внешний ключ на ту же таблицу
• Образует цепь: версия 1 → версия 2 → версия 3
• Позволяет отследить всю историю изменений

Пример 4: Сотрудники и руководители

Сценарий: каждый сотрудник может иметь руководителя, который тоже сотрудник.

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100),
    manager_id INT FOREIGN KEY REFERENCES employees(employee_id)
);

Объяснение:

• employee_id — первичный ключ
• manager_id — внешний ключ на ту же таблицу
• Позволяет построить иерархию: CEO → VP → Manager → Employee
• Руководитель может быть NULL для CEO

Типы связей, где это встречается

1. Один-к-одному (One-to-One)

• Когда: Каждой записи таблицы A соответствует ровно одна запись таблицы B
• Где: user → user_profile, person → passport, employee → workspace
• Зачем: Разделение больших таблиц, опциональные данные
• Пример:

  CREATE TABLE users (
      user_id INT PRIMARY KEY,
      email VARCHAR(100)
  );
  
  CREATE TABLE preferences (
      user_id INT PRIMARY KEY,
      user_id INT FOREIGN KEY REFERENCES users(user_id) ON DELETE CASCADE,
      theme VARCHAR(20),
      language VARCHAR(5)
  );
  

2. Саморефернция (Self-Reference)

• Когда: Таблица ссылается сама на себя
• Где: категории с иерархией, сотрудники с руководителями, файлы с родительской папкой
• Зачем: Построение древообразных структур
• Пример:

  CREATE TABLE folders (
      folder_id INT PRIMARY KEY,
      name VARCHAR(100),
      parent_folder_id INT FOREIGN KEY REFERENCES folders(folder_id)
  );
  

Синтаксис в разных базах данных

PostgreSQL

CREATE TABLE user_profiles (
    user_id SERIAL PRIMARY KEY,
    -- одновременно первичный ключ и внешний ключ
    FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE
);

MySQL

CREATE TABLE user_profiles (
    user_id INT PRIMARY KEY,
    name VARCHAR(100),
    KEY fk_user (user_id),
    CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE
);

SQL Server

CREATE TABLE user_profiles (
    user_id INT PRIMARY KEY,
    name VARCHAR(100),
    FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE
);

Constraints и правила целостности

Когда одно поле является и PK и FK, важно понимать:

ON DELETE CASCADE

• Если запись в родительской таблице удаляется, зависимая запись тоже удаляется
• Пример: удалили пользователя → его профиль тоже удалился
• Опасно для критичных данных

ON DELETE RESTRICT / NO ACTION

• Не позволяет удалить родительскую запись, если на неё есть ссылка
• Безопаснее, но требует явного удаления зависимостей

ON DELETE SET NULL

• При удалении родителя внешний ключ становится NULL
• Используется когда связь опциональна
• Внимание: если это одновременно PK, этого делать нельзя (PK не может быть NULL)

Плюсы и минусы такого подхода

Плюсы:

• Гарантирует один-к-одному связь (на уровне БД, а не приложения)
• Экономит место (не нужна отдельная колонка для FK)
• Простота и ясность схемы
• Легко отследить связь

Минусы:

• Менее гибко (нельзя иметь записи без связи, если PK = FK)
• Может быть сложнее для понимания новичками
• Требует внимательности с миграциями БД

Альтернатива: отдельная колонка для FK

Иногда вместо этого используют отдельную колонку:

-- Вариант 1: PK и FK в разных колонках (рекомендуется часто)
CREATE TABLE user_profiles (
    profile_id INT PRIMARY KEY,  -- первичный ключ
    user_id INT UNIQUE NOT NULL,  -- внешний ключ
    FOREIGN KEY (user_id) REFERENCES users(user_id)
);

-- Вариант 2: PK и FK в одной колонке (то, что мы обсуждали)
CREATE TABLE user_profiles (
    user_id INT PRIMARY KEY,  -- и первичный, и внешний ключ
    FOREIGN KEY (user_id) REFERENCES users(user_id)
);

Когда использовать что:

• PK и FK в разных колонках: Когда нужна независимость идентификаторов
• PK и FK в одной: Когда связь один-к-одному гарантирована и неизменяема

Практические советы для BA

1. Понимай бизнес-логику

   • Спроси себя: "Может ли профиль существовать без пользователя?"
   • Если нет → используй PK + FK в одной колонке
   • Если да → используй отдельные колонки

2. Документируй связи

   • В ERD диаграмме чётко покажи связи
   • В комментариях объясни, почему выбран такой подход

3. Проверяй каскадное удаление

   • Если используешь ON DELETE CASCADE, убедись, что это нужно
   • Иначе данные могут случайно удалиться

4. Миграции

   • При изменении структуры помни о существующих данных
   • Проверь целостность ссылок перед изменением

Заключение

Да, одно поле может быть одновременно первичным и внешним ключом. Это нормально и часто встречается в хороших проектированиях баз данных. Это позволяет:

• Гарантировать отношение один-к-одному
• Упростить структуру таблиц
• Улучшить целостность данных

Одна из важных задач Business Analyst при проектировании данных — понимать эти различия и помочь разработчикам выбрать правильный подход в зависимости от требований бизнеса.