4655. При интеграции с внешним API платежной системы вам необходимо ежедневно сохрачать полный JSON-ответ от них для аудита и отладки. Структура ответа сложная и часто меняется. Какой подход к хранению в БД наиболее рационален?
Anonymous Quiz
30%
Создать реляционную схему, максимально соответствующую JSON, и парсить данные в нее.
48%
Хранить «как есть» в поле типа JSONB (в PostgreSQL) или аналогичном.
18%
Сохранять JSON в виде простого текста (TEXT / CLOB).
4%
Не хранить в БД, а писать сразу в файлы на диске.
👩🏫Объяснение:
Это практический кейс, где нужна гибкость схемы. Современные реляционные СУБД (PostgreSQL, MySQL) имеют специализированные JSON-типы (JSONB), которые позволяют хранить, запрашивать и индексировать данные внутри JSON-документа. Это намного эффективнее, чем хранить JSON как простой текст (C), и гибче, чем создавать жесткую реляционную схему (A), которую придется менять при каждом обновлении API. Прямое сохранение в файлы (D) лишает вас преимуществ транзакционности и SQL-запросов.
4656. Вы проектируете схему БД для блога. Нужно реализовать функцию «лайков» под статьями и комментариями. Ожидаются миллионы пользователей и активные взаимодействия. Как лучше смоделировать хранение лайков?
Anonymous Quiz
27%
Добавить в таблицы Articles и Comments счетчики likes_count и увеличивать их при лайке.
6%
Хранить массив liked_user_ids в записи статьи или комментария.
37%
Для статей и комментариев создать отдельные таблицы Article_Likes и Comment_Likes.
29%
Создать одну таблицу Likes с полями: user_id, target_type (статья/комментарий), target_id.
👩🏫Объяснение:
Вариант A (только счетчик) не позволяет проверить, поставил ли конкретный пользователь лайк (чтобы убрать его), и уязвим для накруток. Вариант D (одна таблица с полиморфной связью) — распространенный и гибкий паттерн. Он позволяет одним запросом получить все лайки пользователя и легко обеспечить уникальность (чтобы один пользователь не лайкнул дважды). Вариант C (отдельные таблицы) ведет к дублированию структуры. Вариант B (массив) плохо масштабируется и неэффективен для выборок в реляционной БД.
4657. В производственную БД интернет-магазина нужно добавить новое обязательное поле external_system_id в крупную таблицу Customers. Поле уже заполнено для новых клиентов. Какая операция ALTER TABLE наиболее безопасна для выполнения на рабочей системе?
Anonymous Quiz
40%
ALTER TABLE customers ADD COLUMN external_system_id INT NULL обновить данные, затем сделать NOT NULL
10%
ALTER TABLE customers ADD COLUMN external_system_id INT NOT NULL;
27%
ALTER TABLE customers ADD COLUMN external_system_id INT NOT NULL DEFAULT 0;
23%
Создать новую таблицу с нужной структурой и переливать данные постепенно.
👩🏫Объяснение:
В большинстве СУБД (особенно старых версий MySQL) добавление колонки с NOT NULL и без DEFAULT к большой таблице вызовет долгую блокирующую операцию и простои. Самый безопасный подход: 1) Добавить колонку как NULLABLE (это быстрая мета-операция). 2) Фоном заполнить ее значениями. 3) Установить ограничение NOT NULL. Вариант C с DEFAULT в некоторых СУБД также может привести к перестройке всей таблицы. Вариант D — чрезмерно сложен для такой задачи.
В большинстве СУБД (особенно старых версий MySQL) добавление колонки с NOT NULL и без DEFAULT к большой таблице вызовет долгую блокирующую операцию и простои. Самый безопасный подход: 1) Добавить колонку как NULLABLE (это быстрая мета-операция). 2) Фоном заполнить ее значениями. 3) Установить ограничение NOT NULL. Вариант C с DEFAULT в некоторых СУБД также может привести к перестройке всей таблицы. Вариант D — чрезмерно сложен для такой задачи.
4658. Вы анализируете проблему: в системе бронирования после оплаты иногда создается билет, но статус заказа не обновляется с «Ожидает оплаты» на «Оплачен». Какой механизм БД должен был гарантировать целостность этой операции?
Anonymous Quiz
5%
FOREIGN KEY
25%
TRIGGER
70%
TRANSACTION
0%
VIEW
👩🏫Объяснение:
Это прямая иллюстрация принципа атомарности из ACID. Операция «списать деньги + создать билет + обновить статус заказа» должна выполняться как единая транзакция. Если любой шаг fails, ROLLBACK откатывает всё. Без транзакции при сбое после создания билета возникает рассогласование. FOREIGN KEY (A) гарантирует целостность связей, TRIGGER (B) — автоматизацию действий, VIEW (D) — виртуальное представление, но ничто из этого не обеспечивает атомарность группы запросов.
4659. При слиянии двух компаний необходимо объединить данных о клиентах из двух независимых БД. В обеих есть таблицы users. Поля частично совпадают (email, phone), но ID-шники разные. Какой процесс НЕ является частью решения этой задачи?
Anonymous Quiz
16%
ETL (Extract, Transform, Load)
8%
Дедупликация записей
64%
Репликация Master-Slave
12%
Сопоставление (Matching) сущностей
👩🏫Объяснение:
Миграция и консолидация данных — сложный практический кейс. Ключевые этапы: извлечение данных из источников, трансформация (приведение к общей схеме), сопоставление (определение, что записи из разных БД относятся к одному клиенту), дедупликация (устранение дублей) и, наконец, загрузка в целевую систему. Это и есть ETL-процесс. Репликация Master-Slave — это механизм копирования данных из основной БД в резервную для отказоустойчивости или чтения, но не для слияния двух разных схем. Она не решает проблему консолидации.
4660. В системе управления складом есть таблица StockMovements с миллионами записей о перемещениях товаров. Для формирования отчета нужно часто вычислять сумму приходов и расходов. Что будет самым эффективным решением для ускорения таких отчетов?
Anonymous Quiz
33%
Создать материализованное представление (materialized view), которое ежедневно пересчитывает остатки
15%
Каждый раз выполнять агрегирующий запрос с SUM() и GROUP BY, добавив индекс на product_id и date
37%
Завести таблицу CurrentStock, которую обновлять триггером при каждой операции движения.
15%
Перейти на колоночную СУБД (например, ClickHouse) для хранения исторических движений.
❤1
👩🏫Объяснение:
Это классическая задача баланса между оперативными транзакциями и аналитическими запросами. Материализованное представление — это «снимок» результата запроса, физически сохраненный в БД, который можно периодически обновлять (например, ночью). Это идеально подходит для ежедневных отчетов, где не нужны данные в реальном времени. Вариант B неэффективен при большом объеме данных, вариант C усложнит транзакции и может стать узким местом, а вариант D — слишком радикальное архитектурное изменение для одной задачи.
4661. При проектировании высоконагруженного чата вы решили хранить сообщения в реляционной БД.. Какой подход к первичному ключу таблицы Messages наиболее оптимален?
Anonymous Quiz
18%
INT AUTO_INCREMENT (последовательный числовой)
23%
UUID (случайный универсальный идентификатор)
34%
BIGINT, генерируемый распределенной Snowflake-алгоритмом
25%
Составной ключ (dialog_id, created_at)
👩🏫Объяснение:
Для высоконагруженных систем с горизонтальным масштабированием (шардингом) важны распределенные и временно-упорядоченные идентификаторы. AUTO_INCREMENT (A) создает горячую точку (hotspot) на одном сервере и не подходит для шардинга. UUID (B) случайный, что убивает локальность данных и приводит к фрагментации индексов, ухудшая производительность вставки и выборки. Snowflake-алгоритм (C) генерирует монотонно возрастающие ID, которые упорядочены по времени и уникальны в распределенной среде — это оптимально для шардинга и кластеризованных индексов. Составной ключ (D) усложняет связи и не является глобально уникальным.