Когда следует использовать FOREIGN KEY в базе данных?

Ну, слушай, вот есть у тебя таблица с заказами, а есть таблица с клиентами. И если какой-то умник впишет в заказ ID клиента, которого в природе не существует, то что мы получим? Правильно, пиздец и бардак. Заказ висит в воздухе, непонятно чей он, и кто за него платить должен.

Вот чтобы такого не было, и придумали внешние ключи, или FOREIGN KEY. Это такая железобетонная привязка одной таблицы к другой. Говоришь базе: «Смотри, чувак, вот этот столбец customer_id в таблице orders — это не просто цифра. Это святая святых, это ссылка на id в таблице customers. И ты, база, обязана следить, чтобы эта связь не порвалась».

Зачем это, блядь, нужно на практике:

1. Чтобы не было хуйни в данных. База просто не даст тебе вписать в заказ customer_id = 999, если клиента с таким айдишником нет. Выдаст ошибку, типа «нету такого, иди нахуй, исправляй». Это и есть целостность.
2. Чтобы автоматически чистить мусор. Допустим, удалили клиента. А что с его заказами? Они же теперь ничьи, болтаются как мусор. Можно настроить внешний ключ так, чтобы при удалении клиента все его заказа тоже автоматом сносились (ON DELETE CASCADE). Жестоко, но справедливо. Или можно просто обнулить customer_id у этих заказов (ON DELETE SET NULL). Главное — не оставить зависших записей.
3. Чтобы JOIN'ы летали. Когда ты связываешь таблицы через WHERE или JOIN, база, зная про внешний ключ, может построить оптимальный план запроса. Это как дать ей карту местности вместо того, чтобы она сама всё на ощупь искала.

Вот смотри, как это выглядит в коде:

-- Таблица клиентов. Главная, родная.
CREATE TABLE customers (
    id INT PRIMARY KEY, -- Вот этот id — святыня.
    name VARCHAR(100) NOT NULL
);

-- Таблица заказов. Подчинённая, привязанная.
CREATE TABLE orders (
    id INT PRIMARY KEY,
    customer_id INT NOT NULL, -- Сюда будем писать id из customers
    total DECIMAL(10,2),
    -- А вот и магия. Объявляем, что customer_id ссылается на customers.id
    CONSTRAINT fk_orders_customer
        FOREIGN KEY (customer_id)
        REFERENCES customers(id)
        ON DELETE CASCADE -- Вот это настройка: удалили клиента — удаляются и его заказы.
        ON UPDATE NO ACTION -- А если поменяли id клиента, то тут ничего не делаем (запрещаем).
);

Что важно запомнить:

• Столбец, на который ссылаешься (customers.id), должен быть PRIMARY KEY или UNIQUE.
• Типы данных у связываемых столбцов должны быть одинаковыми. Нельзя INT привязать к VARCHAR, это же бред.
• Каскадные действия (CASCADE, SET NULL) — мощная штука. Включай с мозгом, а то одним удалением можешь нечаянно полбазы выкосить, ёпта.

Короче, внешний ключ — это не просто «удобно». Это фундамент, на котором стоит нормальная, неразваливающаяся структура базы. Без него твои данные превращаются в свалку, где всё связано через жопу и надежду.