Теоретический конспект: Организация интерфейса с пользователем — контроль

1. Архитектура эшелонированного контроля и блок-схема потока данных

В современных информационных системах пользовательский интерфейс отделен от СУБД сетевым уровнем. Любые данные, вводимые человеком через формы на веб-странице или в мобильном приложении, проходят многоступенчатую цепочку проверок. В промышленной архитектуре реализуется принцип «Defense in Depth» (эшелонированная оборона):

2. Сравнительная характеристика клиентского и серверного контроля

Распределение ответственности между уровнями архитектуры представлено в сравнительной таблице:

3. Правила составления регулярных выражений для валидации экранных форм

Регулярные выражения (Regular Expressions, RegExp) являются стандартом де-факто для проверки формата текстовых данных в формах ввода.

3.1. Фундаментальное правило: граничные якоря ^ и $

Самая распространенная ошибка разработчиков — отсутствие якорей начала строки (^) и конца строки ($). Без якорей регулярное выражение ищет любое совпадение в подстроке, что делает валидацию фиктивной:

// НЕПРАВИЛЬНО (без якорей):
const badRegex = /\d{10}/;
badRegex.test("Мой ИНН 1234567890 и еще мусор"); // Вернет TRUE! (пропустит грязь в БД)

// ПРАВИЛЬНО (строго от начала до конца):
const goodRegex = /^\d{10}$/;
goodRegex.test("1234567890");                   // TRUE (ровно 10 цифр)
goodRegex.test("Мой ИНН 1234567890");          // FALSE (отклонено)

3.2. Стандартные шаблоны валидации реквизитов

3.3. Клиентская проверка контрольных сумм (Алгоритм ИНН-10)

Одной лишь проверки регулярным выражением ^\d{10}$ недостаточно, так как 10-й знак ИНН юридического лица является контрольным разрядом, вычисляемым по специальным весовым коэффициентам:

// Алгоритм проверки контрольного разряда ИНН 10 знаков:
function validateInn10(inn) {
    if (!/^\d{10}$/.test(inn)) return false;
    const weights = [2, 4, 10, 3, 5, 9, 4, 6, 8];
    let sum = 0;
    for (let i = 0; i < 9; i++) {
        sum += parseInt(inn[i], 10) * weights[i];
    }
    const checkDigit = (sum % 11) % 10;
    return checkDigit === parseInt(inn[9], 10);
}

4. Защита от SQL-инъекций: параметризованные запросы (Prepared Statements)

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

Почему параметризация дает 100% защиту?
Параметризованный запрос разделяет выполнение на два независимых этапа:

1. Компиляция (PREPARE): СУБД компилирует запрос с маркерами параметров (плейсхолдерами $1, $2) в бинарное дерево синтаксического разбора (AST — Abstract Syntax Tree). Структура запроса жестко фиксируется в памяти.
2. Исполнение (EXECUTE): Значения параметров передаются отдельно по протоколу передачи данных. Интерпретатор СУБД обрабатывает их строго как константные литералы соответствующего типа (строка, число, дата). Даже если параметр содержит символы ' ; -- DROP TABLE, они не могут выйти за рамки строкового значения и не могут быть выполнены как код!

-- Как параметризация выглядит на уровне протокола PostgreSQL:
-- Шаг 1: Подготовка запроса с типами параметров
PREPARE find_user (text, text) AS
    SELECT id, email, full_name FROM users WHERE login = $1 AND password_hash = $2;

-- Шаг 2: Безопасное выполнение с любыми специальными символами
EXECUTE find_user('admin\' OR 1=1 --', 'secret_hash_value');
-- Запрос будет искать пользователя с буквальным логином "admin' OR 1=1 --" и не вернет лишних данных!

5. Серверный контроль: триггеры BEFORE и изоляция транзакций

Некоторые бизнес-правила невозможно выразить статическим предикатом CHECK (например, проверка наличия товара на складе перед созданием заказа или списание баланса с лицевого счета). Для таких задач в СУБД применяются серверные триггеры BEFORE INSERT OR UPDATE и транзакционные блокировки.

5.1. Пример серверного триггера проверки остатка товара (PostgreSQL)

CREATE OR REPLACE FUNCTION check_stock_availability()
RETURNS TRIGGER AS $$
DECLARE
    current_stock INT;
BEGIN
    -- Блокируем строку товара для предотвращения параллельного изменения остатка
    SELECT stock_quantity INTO current_stock
    FROM warehouse_products
    WHERE product_id = NEW.product_id
    FOR UPDATE;

    IF current_stock < NEW.quantity THEN
        RAISE EXCEPTION 'Недостаточно товара на складе: запрошено %, в наличии %',
            NEW.quantity, current_stock
            USING ERRCODE = 'check_violation';
    END IF;

    -- Автоматически уменьшаем складской остаток
    UPDATE warehouse_products
    SET stock_quantity = stock_quantity - NEW.quantity
    WHERE product_id = NEW.product_id;

    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_check_stock
BEFORE INSERT ON order_items
FOR EACH ROW
EXECUTE FUNCTION check_stock_availability();

5.2. Проблема Race Condition и почему SELECT перед INSERT не работает

Начинающие разработчики часто пишут в коде бэкенда:

// Антипаттерн "Проверка перед вставкой":
if (db.query("SELECT COUNT(*) FROM bookings WHERE room_id = 1 AND date = '2026-10-15'") == 0) {
    db.query("INSERT INTO bookings (room_id, date) VALUES (1, '2026-10-15')");
}

Если два пользователя нажмут кнопку одновременно, оба параллельных потока выполнят SELECT, оба получат результат 0, после чего оба выполнят INSERT. В результате в базе образуется овербукинг (двойное бронирование)!
Решение на уровне СУБД: создание уникального индекса UNIQUE (room_id, booking_date) или ограничения исключения EXCLUDE USING gist (room_id WITH =, booking_range WITH &&). В этом случае СУБД аппаратно заблокирует вторую транзакцию и вернет ошибку 23505 или 23P01.

6. Обработка ошибок СУБД и трансляция в пользовательский интерфейс (Error Mapping)

В случае отказа транзакции на стороне СУБД сервер приложений обязан перехватить исключение, извлечь код SQLSTATE и сопоставить его со словарем дружественных экранных сообщений.

7. Вопросы для самопроверки и закрепления