4720. Вы проектируете базу данных для магазина. В одной таблице Orders вы планируете хранить: order_id, customer_name, customer_phone, product_id, product_name, product_price, quantity, order_date. Какая проблема скорее всего возникнет при таком дизайне?
Anonymous Quiz
4%
Невозможность быстрого поиска по дате
80%
Избыточность данных и аномалии обновления
13%
Отсутствие первичного ключа
3%
Медленная вставка новых записей
Аномалии обновления: если клиент сменил телефон, придётся обновлять все его заказы.
Аномалии вставки: нельзя добавить нового клиента без заказа.
Аномалии удаления: при удалении последнего заказа потеряется информация о клиенте.
❌ A: Поиск по дате можно ускорить индексом, это не главная проблема.
❌ C: Первичный ключ (order_id) есть, его можно добавить.
❌ D: Вставка может быть не медленной, а вот обновления — да.
Вывод: Правильное проектирование требует выделения сущностей (Клиенты, Товары, Заказы) в отдельные таблицы и установления связей между ними.
Please open Telegram to view this post
VIEW IN TELEGRAM
4721. В банковской системе выполняется перевод средств со счёта A на счёт B. Операция состоит из двух шагов: списание с A и зачисление на B. После списания, но до зачисления - сбой. Какое свойство транзакции нарушено,и каким механизмом оно обеспечивается?
Anonymous Quiz
28%
Согласованность (Consistency) — через триггеры
12%
Изоляция (Isolation) — через блокировки
58%
Атомарность (Atomicity) — через журнал транзакций (WAL)
2%
Долговечность (Durability) — через резервное копирование
❌ A: Согласованность отвечает за сохранение бизнес-правил (например, баланс не становится отрицательным), но не за откат при сбое.
❌ B: Изоляция защищает от влияния параллельных транзакций, не от сбоев.
❌ D: Долговечность гарантирует, что завершённая транзакция сохранится, но не откат.
Вывод: Атомарность — фундаментальное свойство транзакций, критичное для финансовых операций.
Please open Telegram to view this post
VIEW IN TELEGRAM
4722. В таблице Users (10 млн записей) часто выполняются запросы поиска пользователей по полю email. Какое действие даст наибольший прирост производительности?
Anonymous Quiz
65%
Создать индекс по полю email
3%
Увеличить размер оперативной памяти сервера
22%
Добавить составной индекс по полям (email, last_name)
10%
Разделить таблицу на несколько по первой букве email
❌ B: Увеличение памяти может помочь, если текущий объём недостаточен для кэширования, но это не решит проблему полного сканирования.
❌ C: Составной индекс полезен, если запросы часто используют оба поля, но для поиска только по email он будет менее эффективен (можно использовать, но он больше по размеру).
❌ D: Шардинг (горизонтальное партиционирование) — сложное архитектурное решение, которое обычно применяют при распределении нагрузки, а не для ускорения одного вида запросов. Индекс проще и дешевле.
Вывод: Индекс — базовый инструмент оптимизации запросов. Аналитик должен рекомендовать индексацию часто используемых в условиях WHERE полей.
Please open Telegram to view this post
VIEW IN TELEGRAM
4723. В системе онлайн-бронирования отелей два пользователя одновременно пытаются забронировать последний свободный номер. В результате номер забронирован дважды. Какой механизм СУБД предотвратил бы эту проблему?
Anonymous Quiz
9%
Уникальный индекс на поле room_id
17%
Триггер, проверяющий количество броней
73%
Блокировка строки при чтении (SELECT ... FOR UPDATE)
1%
Журналирование всех изменений
Добавьте папку — и сразу получите доступ к закрытому каналу с подарками от экспертов: полезными гайдами, чек-листами, промокодами на карьерные консультации и т.д.
🍂 Карьерный рост — стратегии переговоров, продажи, маркетинг🍂 Удалёнка и фриланс — как находить заказчиков и работать из любой точки мира🍂 Личный бренд — создание экспертного статуса🍂 Hard и soft skills — навыки, за которые готовы платить в 2026 года🍂 Автоматизация и тайм-менеджмент — как работать меньше, а зарабатывать больше и многое другое
Добавить папку + открыть бонусы
https://t.me/addlist/ZcC3dzQ0ZJhjZjgy
(Доступ открыт 72 часа)
Присоединяйтесь: @prodvizheniye_reklama
Please open Telegram to view this post
VIEW IN TELEGRAM
❌ A: Уникальный индекс предотвращает дубликаты по ключу, но здесь уникальность не в одном поле, а в сочетании «номер + дата» (или что-то подобное). Если бы индекс был составным, он бы сработал, но в условии только room_id — не хватит.
❌ B: Триггер выполняется после попытки вставки, но не блокирует чтение, поэтому оба пользователя могут пройти проверку одновременно.
❌ D: Журналирование помогает при восстановлении после сбоя, но не решает проблему конкурентного доступа.
Вывод: Для критичных по конкуренции операций необходимо использовать явные блокировки или повышать уровень изоляции транзакции до REPEATABLE READ / SERIALIZABLE.
Please open Telegram to view this post
VIEW IN TELEGRAM
4724. Для нового проекта — системы мониторинга IoT-датчиков — нужно хранить поток показаний. Каждое событие: ID датчика, временная метка, значение. Требуется быстрая запись и аналитика по временным диапазонам. Какую базу данных лучше выбрать?
Anonymous Quiz
17%
Реляционную (PostgreSQL) с нормализованной схемой
10%
Документную (MongoDB)
68%
Колоночную временную (Time Series DB) — например, InfluxDB или ClickHouse
6%
Графовую (Neo4j)
❌ A: Реляционные БД справляются с временными рядами, но при 100k событий/сек быстро упрутся в ограничения по записи и объёму, если не использовать специализированные расширения (например, TimescaleDB для PostgreSQL — но это уже гибрид).
❌ B: MongoDB хорошо подходит для документов, но не оптимизирована для временных агрегаций на больших объёмах.
❌ D: Графовые БД нужны для анализа связей (социальные сети, рекомендации), здесь они не релевантны.
Вывод: Аналитик должен понимать классы СУБД и выбирать под задачу: для временных рядов — специализированные хранилища.
Please open Telegram to view this post
VIEW IN TELEGRAM
4724. Новостной портал с миллионной аудиторией, высокая нагрузка на чтение, небольшая команда, быстрое развитие. Какую архитектуру выбрать на старте?
Anonymous Quiz
19%
Микросервисная
55%
Модульный монолит
9%
Serverless
17%
Событийно-ориентированная
Быстро разрабатывать и развертывать (единое приложение, простая инфраструктура).
Чётко разделить код на модули (например, статьи, комментарии, пользователи), что в будущем позволит безболезненно выделить микросервисы.
Эффективно использовать ресурсы: один процесс обрабатывает запросы без сетевых задержек между сервисами.
❌ Микросервисная архитектура (A) на старте приведёт к излишней сложности: нужно настраивать межсервисное взаимодействие, обеспечивать согласованность данных, управлять конфигурациями нескольких сервисов — для небольшой команды это замедлит разработку.
❌ Serverless (C) может дать холодный старт при первом обращении к статье, что ухудшит пользовательский опыт. Кроме того, serverless сложнее отлаживать и тестировать локально, а также возможен vendor lock-in.
❌ Событийно-ориентированная архитектура (D) с брокером сообщений избыточна для новостного портала, где основная логика синхронна (отдать статью). Она добавит сложности без явной выгоды.
Вывод: Для большинства стартапов с монолитной предметной областью и небольшой командой модульный монолит — разумный выбор, позволяющий сохранить гибкость и скорость.
Please open Telegram to view this post
VIEW IN TELEGRAM
4725. Система бронирования авиабилетов. Как не допустить двойную продажу одного места при одновременных запросах?
Anonymous Quiz
5%
Оптимистическая блокировка
71%
Пессимистическая блокировка (SELECT FOR UPDATE)
10%
Уникальный индекс на (рейс, место)
13%
Очередь запросов
SELECT ... FOR UPDATE в начале транзакции блокирует строку до её завершения. Второй пользователь, попытавшийся выполнить такой же запрос, будет ждать освобождения блокировки и увидит, что место уже занято.
Этот подход гарантирует, что два пользователя не смогут одновременно начать бронирование одного места.
❌ Оптимистическая блокировка (A) предполагает проверку версии при обновлении. При высокой конкуренции оба пользователя могут прочитать место как свободное, и только при попытке записи один получит ошибку. Это допустимо, но пользователь получит отказ после ввода данных, что хуже для UX.
❌ Уникальный индекс (C) предотвращает дубликаты на уровне вставки, но не защищает от чтения: оба могут попытаться вставить, и одна вставка упадёт с ошибкой дубликата. Опять же, пользователь узнаёт об отказе после попытки.
❌ Очередь (D) сериализует запросы, но добавляет задержку и сложность. При этом первый запрос в очереди может занять место, а остальные увидят отказ. Однако реализация очереди и обработка таймаутов сложнее, чем блокировка в БД.
Вывод: Для критичных по конкурентности операций с уникальным ресурсом (место, товар) выбирайте пессимистическую блокировку — она даёт наилучший UX и простоту реализации.
Please open Telegram to view this post
VIEW IN TELEGRAM