4652. При частых операциях JOIN между очень большими таблицами Orders и Customers производительность падает. Какая оптимизация будет наиболее эффективной?
Anonymous Quiz
0%
Увеличить объем оперативной памяти на сервере БД.
8%
Отказаться от использования JOIN и делать два последовательных запроса.
51%
Денормализовать данные: добавить часто запрашиваемые поля из Customers прямо в таблицу Orders.
41%
Создать материализованное представление (Materialized View) с уже объединенными данными.
👩🏫Объяснение:
Денормализация — это сознательное нарушение нормальных форм для увеличения скорости чтения, путем исключения дорогостоящего JOIN. Материализованное представление — это «снимок» результата JOIN, который периодически обновляется. Это классический trade-off между скоростью чтения и актуальностью данных. Увеличение памяти может помочь, но не решит проблему кардинально. Два последовательных запроса (3) часто работают еще медленнее.
4653. Вы аналитик в стартапе по доставке еды. При проектировании БД для сущности «Заказ» выяснилось, что один заказ может содержать несколько блюд, а одно блюдо может фигурировать в разных заказах. Как правильно смоделировать эту связь?
Anonymous Quiz
1%
Добавить в таблицу Order повторяющиеся столбцы Dish_1, Dish_2 и т.д.
14%
В таблицу Order добавить столбец Dish_ID, который будет ссылаться на блюдо.
74%
Создать две таблицы: Order и Dish, и связующую таблицу Order_Dish с order_id и dish_id.
10%
Хранить список ID блюд в виде JSON-массива в одном столбце dishes таблицы Order.
❤1
👩🏫Объяснение:
Это классический пример связи «многие ко многим» (many-to-many). Один заказ содержит много блюд, одно блюдо входит в многие заказы. Корректная и нормализованная модель в реляционной БД — создание связующей (junction) таблицы. Вариант A нарушает 1НФ (повторяющиеся группы), B — подразумевает связь «один ко многим» (одно блюдо в заказе), а D (хранение массива) хоть и используется в NoSQL, в реляционной БД усложнит агрегацию, отчетность и целостность данных на уровне СУБД.
4654. В системе электронных билетов пользователи жалуются на медленную загрузку «Истории заказов». Страница формируется запросом с JOIN 4-х таблиц и сортировкой по дате. Индексы расставлены на первичные ключи. Что, скорее всего, ускорит выборку данных?
Anonymous Quiz
38%
Добавить составной индекс на поля, используемые в условиях WHERE и ORDER BY.
5%
Увеличить размер оперативной памяти на сервере БД.
52%
Денормализовать данные, создав таблицу User_Order_History, которая обновляется триггерами.
6%
Разделить (shard) базу данных по первым буквам email пользователей.
👩🏫Объяснение:
Частая причина медленных запросов — отсутствие правильных индексов под конкретную нагрузку. Индексы на PK ускоряют поиск по ID, но не по условиям WHERE или сортировке. Составной индекс, покрывающий фильтрацию и сортировку, кардинально ускорит запрос. Варианты B, C, D — это более тяжелые архитектурные изменения, которые уместны, если оптимизация индексов и запросов уже не помогает. Начинать всегда нужно с анализа плана запроса (EXPLAIN) и индексов.
Частая причина медленных запросов — отсутствие правильных индексов под конкретную нагрузку. Индексы на PK ускоряют поиск по ID, но не по условиям WHERE или сортировке. Составной индекс, покрывающий фильтрацию и сортировку, кардинально ускорит запрос. Варианты B, C, D — это более тяжелые архитектурные изменения, которые уместны, если оптимизация индексов и запросов уже не помогает. Начинать всегда нужно с анализа плана запроса (EXPLAIN) и индексов.
4655. При интеграции с внешним API платежной системы вам необходимо ежедневно сохрачать полный JSON-ответ от них для аудита и отладки. Структура ответа сложная и часто меняется. Какой подход к хранению в БД наиболее рационален?
Anonymous Quiz
33%
Создать реляционную схему, максимально соответствующую JSON, и парсить данные в нее.
51%
Хранить «как есть» в поле типа JSONB (в PostgreSQL) или аналогичном.
11%
Сохранять JSON в виде простого текста (TEXT / CLOB).
5%
Не хранить в БД, а писать сразу в файлы на диске.
👩🏫Объяснение:
Это практический кейс, где нужна гибкость схемы. Современные реляционные СУБД (PostgreSQL, MySQL) имеют специализированные JSON-типы (JSONB), которые позволяют хранить, запрашивать и индексировать данные внутри JSON-документа. Это намного эффективнее, чем хранить JSON как простой текст (C), и гибче, чем создавать жесткую реляционную схему (A), которую придется менять при каждом обновлении API. Прямое сохранение в файлы (D) лишает вас преимуществ транзакционности и SQL-запросов.
В 2026 бизнес- и системный анализ стали точкой, где принимаются самые дорогие решения.
СОБРАЛИ ПАПКУ — про аналитиков, которые:
— связывают бизнес-цели, процессы и IT-решения
— работают с ИИ как инструментом, а не заменой мышления
— отвечают за результат, а не за документацию
— помогают бизнесу принимать обоснованные решения, а не гадать
Здесь — эксперты по бизнес- и системному анализу, которые работают с реальными кейсами и живыми продуктами.
👉ЗАБРАТЬ ПАПКУ
Сегодня бизнесу недостаточно «описать требования».
Нужны специалисты, которые понимают систему целиком, видят влияние решений на деньги и умеют работать в условиях неопределённости.
СОБРАЛИ ПАПКУ — про аналитиков, которые:
— связывают бизнес-цели, процессы и IT-решения
— работают с ИИ как инструментом, а не заменой мышления
— отвечают за результат, а не за документацию
— помогают бизнесу принимать обоснованные решения, а не гадать
Здесь — эксперты по бизнес- и системному анализу, которые работают с реальными кейсами и живыми продуктами.
👉ЗАБРАТЬ ПАПКУ
❤1
4656. Вы проектируете схему БД для блога. Нужно реализовать функцию «лайков» под статьями и комментариями. Ожидаются миллионы пользователей и активные взаимодействия. Как лучше смоделировать хранение лайков?
Anonymous Quiz
27%
Добавить в таблицы Articles и Comments счетчики likes_count и увеличивать их при лайке.
2%
Хранить массив liked_user_ids в записи статьи или комментария.
38%
Для статей и комментариев создать отдельные таблицы Article_Likes и Comment_Likes.
34%
Создать одну таблицу Likes с полями: user_id, target_type (статья/комментарий), target_id.
👩🏫Объяснение:
Вариант A (только счетчик) не позволяет проверить, поставил ли конкретный пользователь лайк (чтобы убрать его), и уязвим для накруток. Вариант D (одна таблица с полиморфной связью) — распространенный и гибкий паттерн. Он позволяет одним запросом получить все лайки пользователя и легко обеспечить уникальность (чтобы один пользователь не лайкнул дважды). Вариант C (отдельные таблицы) ведет к дублированию структуры. Вариант B (массив) плохо масштабируется и неэффективен для выборок в реляционной БД.
4657. В производственную БД интернет-магазина нужно добавить новое обязательное поле external_system_id в крупную таблицу Customers. Поле уже заполнено для новых клиентов. Какая операция ALTER TABLE наиболее безопасна для выполнения на рабочей системе?
Anonymous Quiz
43%
ALTER TABLE customers ADD COLUMN external_system_id INT NULL обновить данные, затем сделать NOT NULL
12%
ALTER TABLE customers ADD COLUMN external_system_id INT NOT NULL;
26%
ALTER TABLE customers ADD COLUMN external_system_id INT NOT NULL DEFAULT 0;
19%
Создать новую таблицу с нужной структурой и переливать данные постепенно.
👩🏫Объяснение:
В большинстве СУБД (особенно старых версий 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
6%
FOREIGN KEY
24%
TRIGGER
70%
TRANSACTION
0%
VIEW
👩🏫Объяснение:
Это прямая иллюстрация принципа атомарности из ACID. Операция «списать деньги + создать билет + обновить статус заказа» должна выполняться как единая транзакция. Если любой шаг fails, ROLLBACK откатывает всё. Без транзакции при сбое после создания билета возникает рассогласование. FOREIGN KEY (A) гарантирует целостность связей, TRIGGER (B) — автоматизацию действий, VIEW (D) — виртуальное представление, но ничто из этого не обеспечивает атомарность группы запросов.