Из каких ключевых компонентов состоит архитектура реляционной СУБД?

Давай разберём эту вашу реляционную СУБД, как она там внутри устроена, а то некоторые думают, что это просто волшебный ящик, куда SQL-запросы кидаешь, а он тебе результат выплёвывает. Нет, блядь, там целый ёперный театр под капотом!

Смотри, вот как это всё работает, если по-человечьи.

1. Ядро — это, блядь, главный мозг всей этой конструкции. Туда твой SQL-запрос прилетает. Сначала парсер его разбирает, как грамотный дед на буквы, и думает: «А чё это этот юзер хочет, ёпта?». Потом в дело вступает оптимизатор — это такой хитрожопый инженер, который смотрит на этот запрос и начинает прикидывать: «Так, можно вот так сделать, но это будет овердохуища медленно. А можно вот эдак, через тот индекс, который мы в прошлый вторник создали». Он ищет самый быстрый план выполнения, чтобы не тратить силы попусту. А ещё там диспетчер транзакций сидит, который следит за священными принципами ACID. Чтобы если ты начал что-то делать, то либо всё сделал, либо нихуя — атомарность, ёпта! Чтобы данные всегда были консистентные, а не какая-то каша. Чтобы транзакции друг другу не мешали, как в очереди за водкой. И чтобы если сервер внезапно накрылся медным тазом, то после включения всё было как было — это долговечность, мать его. Рядом с ним диспетчер блокировок — он как вышибала в клубе: следит, чтобы два потока в одну и ту же строчку в таблице не полезли одновременно писать, а то будет драка (inconsistent read) и всем пиздец.

2. Логическая структура — это скелет и мышцы. Схема — это как чертёж всей базы, там прописано, что и как называется. Таблицы — это основные залы для хранения данных. Строки, столбцы — всё чинно, благородно. Индексы — вот это, блядь, самое важное! Это как оглавление в толстой книге. Без индекса СУБД будет читать всю книгу от корки до корки, чтобы найти одну фразу (full table scan). А с индексом (чаще всего это B-дерево) — сразу откроет на нужной странице. Создаёшь индекс — запросы летают. Забыл создать — нихуя не летают, все сидят и ждут. Представления (Views) — это такая хитрая жопа. Физически данных там нет, это просто сохранённый запрос. Откроешь view — а он тебе на лету данные из трёх таблиц склеит. Ограничения целостности — это правила внутреннего распорядка. PRIMARY KEY говорит: «В этом столбце все значения должны быть уникальные и не пустые, блядь!». FOREIGN KEY — это как родственная связь: «Эй, чувак, если ты в этой колонке пишешь цифру 5, то в той таблице, на которую ты ссылаешься, запись с id=5 должна существовать, иначе я тебе в сраку!». CHECK — это вообще: «Значение в этой колонке должно быть больше нуля, иначе ни хуя!».

3. Физическое хранилище — это уже работа с диском, с железом. Тут данные пакуются в страницы (pages) и пишутся в файлы. А чтобы не потерять всё, если свет вырубят, используется журнал транзакций (WAL). Принцип простой, как три копейки: сначала любое изменение записывается в журнал (лог), и только потом — в основные файлы данных. Так что если пиздец случился, можно отмотать лог назад или вперёд и всё восстановить. Гениально и просто.

4. Вспомогательные компоненты — обслуга и прислуга. Буферный кэш — это оперативка, выделенная под базу. Часто читаемые страницы с диска кладутся сюда, чтобы не дергать медленный хард каждый раз. Работает по принципу «зачем ходить далеко, если водка рядом». Хранимые процедуры и триггеры — это когда логику из приложения засовывают прямо в базу. Процедура — это как мини-программа на SQL. А триггер — это такая манда с ушами, которая срабатывает автоматически при каком-то событии (вставка, обновление). Например, можно сделать триггер, который после каждого нового заказа будет автоматически обновлять общую сумму у клиента. Удобно, но если наворотить их дохуя, то потом разбираться, кто и когда что меняет, — это пиздец, волнение ебать.

А вот, смотри, как это выглядит в коде, когда ты эти связи создаёшь. Код не трогаю, он святой.

-- Создаём таблицу пользователей. PRIMARY KEY — чтобы id были уникальные.
CREATE TABLE Users (
    id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    username VARCHAR(50) UNIQUE NOT NULL, -- UNIQUE, чтобы не было двух Васьков
    email VARCHAR(100) UNIQUE NOT NULL
);

-- Создаём таблицу заказов. FOREIGN KEY — чтобы заказ был привязан к реальному юзеру.
CREATE TABLE Orders (
    order_id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    user_id INT NOT NULL,
    amount DECIMAL(10,2),
    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_user
        FOREIGN KEY(user_id)
        REFERENCES Users(id) -- Ссылаемся на столбец id в таблице Users
        ON DELETE CASCADE -- Если юзера удалили, все его заказы автоматом летят в пизду
);

Вот и вся магия, блядь. Не просто CREATE TABLE написал, а целую систему отношений построил. Красота!