Можно ли сделать JOIN если не настроены связи между таблицами в БД?

Можно ли делать JOIN без настроенных связей в БД?

Коротко: да, можно. Foreign Key constraints и физические связи в БД — это две разные вещи. JOIN работает на основе логических значений в столбцах, а не на основе constraints. Однако, есть важные нюансы.

Теория: Как на самом деле работает JOIN

// SQL JOIN — это логическая операция над множествами строк
// SELECT a.*, b.* 
// FROM table_a a
// JOIN table_b b ON a.id = b.a_id

// Это эквивалентно (псевдокод):
// result = []
// for row_a in table_a:
//     for row_b in table_b:
//         if row_a.id == row_b.a_id:
//             result.append((row_a, row_b))
// return result

Ключевой момент: JOINы работают на базе совпадения значений в столбцах, не на FK constraints!

Пример: JOIN без Foreign Key

-- Таблица users (БЕЗ любых constraints)
CREATE TABLE users (
    id INTEGER,
    name VARCHAR(100)
);

-- Таблица orders (БЕЗ foreign key)
CREATE TABLE orders (
    id INTEGER,
    user_id INTEGER,
    amount DECIMAL
);

-- Добавим данные
INSERT INTO users VALUES (1, 'Alice');
INSERT INTO users VALUES (2, 'Bob');
INSERT INTO orders VALUES (101, 1, 99.99);
INSERT INTO orders VALUES (102, 2, 149.99);

-- Это РАБОТАЕТ отлично, даже без FK!
SELECT u.name, o.amount
FROM users u
JOIN orders o ON u.id = o.user_id;

-- Результат:
-- name   | amount
-- Alice  | 99.99
-- Bob    | 149.99

Различие: Constraints vs Joins

Проблемы без Foreign Keys

1. Referential Integrity (целостность ссылок)

-- БЕЗ FK constraint это допускается:
INSERT INTO orders (id, user_id, amount) 
VALUES (103, 999, 50.00);  -- user_id не существует!

-- С FK constraint это вернёт ошибку

2. Orphaned Records (потерянные записи)

-- БЕЗ FK, при удалении пользователя:
DELETE FROM users WHERE id = 1;  -- OK

-- Его заказы остаются висеть! (orders.user_id = 1 -> ни на кого)

-- С ON DELETE CASCADE заказы удалялись бы автоматически
DELETE FROM users WHERE id = 1;  -- orders тоже удаляются

3. Плохая оптимизация запросов

-- БЕЗ FK constraints оптимизатор может работать неоптимально
EXPLAIN SELECT * FROM orders o 
JOIN users u ON o.user_id = u.id;

-- С FK constraint оптимизатор использует информацию о связи
-- Может выбрать более эффективный план

Практический пример на C++

#include <sqlite3.h>
#include <iostream>
#include <vector>

struct Order {
    int id;
    int user_id;
    double amount;
    std::string user_name;
};

std::vector<Order> getOrdersWithUsers(sqlite3* db) {
    std::vector<Order> orders;
    
    // Это работает БЕЗ foreign keys
    const char* sql = R"(
        SELECT o.id, o.user_id, o.amount, u.name
        FROM orders o
        JOIN users u ON o.user_id = u.id
        ORDER BY o.id
    )";
    
    sqlite3_stmt* stmt;
    sqlite3_prepare_v2(db, sql, -1, &stmt, nullptr);
    
    while (sqlite3_step(stmt) == SQLITE_ROW) {
        Order order{
            .id = sqlite3_column_int(stmt, 0),
            .user_id = sqlite3_column_int(stmt, 1),
            .amount = sqlite3_column_double(stmt, 2),
            .user_name = (const char*)sqlite3_column_text(stmt, 3)
        };
        orders.push_back(order);
    }
    
    sqlite3_finalize(stmt);
    return orders;
}

Когда FK нужны, а когда нет?

FK нужны когда:

• Важна целостность данных (финансовые системы)
• Нужна каскадное удаление/обновление (автоматическая очистка)
• Требуется защита от логических ошибок при INSERT/UPDATE
• Требуется оптимизация SELECT запросов

FK можно пропустить когда:

• Данные не критичны (логи, analytics)
• Контроль целостности на уровне приложения (ORM)
• Очень высокая нагрузка на INSERT/UPDATE
• Миграция из старой системы

Best Practice

-- Хороский стиль: define FK constraints

CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    name VARCHAR(100) NOT NULL
);

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    amount DECIMAL(10,2),
    
    CONSTRAINT fk_orders_users 
        FOREIGN KEY (user_id) 
        REFERENCES users(id) 
        ON DELETE CASCADE
);

-- Теперь:
-- 1. JOIN работает эффективнее
-- 2. Нельзя создать orphaned orders
-- 3. При удалении пользователя его заказы удаляются

Выводы

Да, JOIN работает БЕЗ FK — это логическая операция над значениями в столбцах.

Однако FK нужны для:

• Гарантии целостности данных
• Автоматического управления связанными записями
• Помощи оптимизатору запросов
• Документирования структуры данных

В production-коде рекомендуется всегда использовать FK constraints для важных связей между таблицами.