inn защищено уникальным ограничением clients_inn_key.
Разработайте JavaScript-логику валидации формы:
^ и $ для формата ИНН (10 цифр) и ОГРН (13 цифр).[2, 4, 10, 3, 5, 9, 4, 6, 8].disabled).В схеме базы данных определена таблица:
CREATE TABLE corporate_clients (
client_id BIGSERIAL PRIMARY KEY,
company_name VARCHAR(255) NOT NULL,
inn CHAR(10) NOT NULL CONSTRAINT clients_inn_key UNIQUE,
ogrn CHAR(13) NOT NULL,
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT chk_inn_digits CHECK (inn ~ '^\d{10}$'),
CONSTRAINT chk_ogrn_digits CHECK (ogrn ~ '^\d{13}$')
);Два разных оператора одновременно попытались зарегистрировать одно и то же юридическое лицо. Ядро СУБД выбросило системное исключение:
ERROR: duplicate key value violates unique constraint "clients_inn_key"
DETAIL: Key (inn)=(7701234567) already exists.
SQLSTATE: 2350523505 и возвращает пользователю дружественное сообщение: «Клиент с данным ИНН уже зарегистрирован».Напишите параметризованный запрос (Prepared Statement) для добавления нового клиента и объясните, почему он полностью защищает от SQL-инъекций даже при наличии специальных символов в названии компании.
^ и $.amount <= 0, вывод подсказки: «Сумма перевода должна быть строго больше нуля».Схема таблицы банковских счетов:
CREATE TABLE bank_accounts (
account_id BIGSERIAL PRIMARY KEY,
account_number CHAR(20) NOT NULL UNIQUE,
bik CHAR(9) NOT NULL,
balance NUMERIC(15,2) NOT NULL DEFAULT 0.00,
CONSTRAINT chk_positive_balance CHECK (balance >= 0.00)
);Злоумышленник отправил запрос через curl в обход браузера на сумму 1 000 000 руб. при реальном остатке на счете 500 руб. СУБД выбросила исключение check_violation (SQLSTATE 23514).
А при параллельном списании денег в двух банкоматах возник конфликт транзакций serialization_failure (SQLSTATE 40001).
SELECT ... FOR UPDATE для корректной пессимистической блокировки счета отправителя на время выполнения перевода.Почему конкатенация строк в финансовой транзакции категорически недопустима? Приведите пример опасного запроса и покажите его безопасный аналог на Prepared Statement.
+7 (XXX) XXX-XX-XX и регулярное выражение для очищенных 11 цифр.Два покупателя одновременно нажали кнопку «Купить» на последнюю единицу товара на складе. В СУБД сработал серверный триггер:
CREATE OR REPLACE FUNCTION trg_check_inventory() RETURNS TRIGGER AS $$
DECLARE v_stock INT;
BEGIN
SELECT stock_quantity INTO v_stock FROM warehouse WHERE product_id = NEW.product_id FOR UPDATE;
IF v_stock < NEW.quantity THEN
RAISE EXCEPTION 'OUT_OF_STOCK: Недостаточно товара на складе' USING ERRCODE = 'P0001';
END IF;
UPDATE warehouse SET stock_quantity = stock_quantity - NEW.quantity WHERE product_id = NEW.product_id;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;FOR UPDATE? Что произойдет со вторым покупателем?SQLSTATE P0001 на бэкенде: какое дружественное сообщение увидит второй покупатель на экране оформления заказа?Опишите, как Prepared Statement обрабатывает вредоносные символы в поле email (например, ' OR 1=1; DROP TABLE orders; --). Почему СУБД не выполняет этот код?
Дата_выезда > Дата_заезда, запрет бронирования в прошлом (дата заезда не может быть раньше сегодняшнего дня).Для предотвращения овербукинга в таблице отеля создано ограничение исключения интервалов:
CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE TABLE room_bookings (
booking_id BIGSERIAL PRIMARY KEY,
room_id INT NOT NULL,
stay_dates DATERANGE NOT NULL,
guest_name VARCHAR(100) NOT NULL,
CONSTRAINT chk_no_overlap EXCLUDE USING gist (
room_id WITH =,
stay_dates WITH &&
)
);Два гостя параллельно отправили заявки на пересекающиеся даты. База данных отвергла вторую транзакцию системной ошибкой:
ERROR: conflicting key value violates exclusion constraint "chk_no_overlap"
DETAIL: Key (room_id, stay_dates)=(101, [2026-10-10, 2026-10-15)) conflicts with existing key...
SQLSTATE: 23P01SQLSTATE 23P01 и выводит гостю подсказку: «Выбранный номер уже занят на эти даты. Пожалуйста, выберите другие даты или другой номер».Сформулируйте параметризованный запрос для вставки бронирования с приведением типов $1::int, daterange($2::date, $3::date, '[)') и обоснуйте его надежность.