4651. Для хранения и сложного поиска по полуструктурированным логам действий пользователей (JSON с разными наборами полей) лучше всего подходит:
Anonymous Quiz
14%
Реляционная БД с заранее определенными колонками.
74%
Документоориентированная NoSQL БД, такая как MongoDB или Elasticsearch.
7%
Классическая SQL БД с хранением JSON в текстовом поле.
5%
Графовая база данных.
👩🏫Объяснение:
Полуструктурированные данные с меняющейся схемой — их родная стихия. Такие БД позволяют хранить каждый документ (лог) с его уникальным набором полей и эффективно индексировать и искать по вложенным атрибутам. Elasticsearch дополнительно дает мощные полнотекстовые и аналитические возможности. Реляционная БД (1) будет требовать сложных миграций при изменении структуры логов, а хранение JSON в текстовом поле (3) резко снизит возможности поиска. Графовая БД (4) предназначена для других задач.
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%
Создать новую таблицу с нужной структурой и переливать данные постепенно.