BA & SA | 10000 Interview questions

№4787 категория вопросов: #INTEGRATION

ИН:Ритейл 21 мая приглашаем всех, кто определяет стратегию развития и маркетинга бизнесов в ритейле, обсудить ситуацию на рынке в новых условиях, вызовы 2026 года и перспективы. Отдельный фокус — на технологиях и инструментах, которые помогают бизнесу отвечать на новые вызовы: как меняется эффективность привлечения, как растёт измеримость рекламных каналов и какую роль играют новые форматы в маркетинговом миксе. Встречаемся 21 мая в Москве. Для тех, кто не сможет приехать, организуем онлайн-трансляцию. Мероприятие бесплатное, нужно только зарегистрироваться. Зарегистрироваться #реклама yandex.ru О рекламодателе

ХОЧЕШЬ ИДТИ В НОГУ С ТЕХНОЛОГИЯМИ ?! … или наблюдать, как другие зарабатывают на ИИ? - РЕШАТЬ ТЕБЕ ! ИИ станет твоим главным инструментом, а не загадкой 🗝 Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя и заодно попали в эту ПОДБОРКУ сами ✔️ Что внутри? Только лучшее из Мира IT & AI : * ИИ — не хайп, а реальные инструменты и внедрения * Технологии — тренды, обзоры, инсайты от первых лиц * Карьера — как найти работу, вырасти и не выгореть * HR Tech — кто и как нанимает профессионалов прямо сейчас * AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ Делимся знаниями и аудиторией - растём вместе ⚡️ Забирай бесплатно ПАПКУ с ТОП ИИ Каналами Твой доступ к подборке и бонусам: ➡️ Просто добавь Папку - никаких смс или регистраций. Отписаться можно в любой момент. Остаться — тоже ✔️ * Ссылка - https://t.me/addlist/r5VfG-YYZB9mNzM8

ПОДПИСКИ НА ИИ-КАНАЛЫ ЕСТЬ, А СВЕЖИХ ИДЕЙ — НОЛЬ !? * Твои подписки устарели (outdated). Пора сделать АПГРЕЙД своего информационного поля. Сегодняшний ИИ — это не «10 крутых промтов» и не новость про ChatGPT-5. Это рабочие связки, реальные кейсы, свежие инструменты, которые сэкономят тебе часы уже на этой неделе. Проблема не в том, что ты мало читаешь. А в том, что ты читаешь не тех ... Мы собрали свежую ПОДБОРКУ каналов, где авторы реально работают с технологиями здесь и сейчас. Никаких повторов и воды. Только практика, кейсы, новые тулы и разборы, которые имеют значение. 📂 Добавляй ПАПКУ — и получи полный АПГРЕЙД своей ленты: ➡️ https://t.me/addlist/r5VfG-YYZB9mNzM8 * Сделай свою подписку умнее, пока другие читают вчерашние новости и не бойся перемен ... Отписаться можно в любой момент. Остаться — тоже ✔️

Куда срочно перенести рабочие чаты? Битрикс24 — мессенджер для работы и бизнеса. Личные и групповые чаты, видеозвонки и каналы в одном сервисе. Приглашайте коллег и внешние команды. Работает как привычный мессенджер. Есть бесплатный тариф. Начните работать уже сейчас. Попробовать #реклама 16+ bitrix24.ru О рекламодателе

☀Объяснение: Суть проблемы: Нужно отфильтровать сгруппированные данные по агрегатной функции (SUM). WHERE применяется до группировки и не может использовать агрегаты. HAVING — после группировки и предназначен именно для фильтрации групп. Разбор вариантов: A (WHERE SUM(...)) — синтаксическая ошибка, WHERE не видит агрегат. B — корректно: сначала группируем по client_id, считаем сумму, потом оставляем только те группы, где сумма > 1 000 000. C — вернёт для каждого клиента булево значение, но не отфильтрует строки. D — WHERE нельзя использовать после GROUP BY (порядок: WHERE → GROUP BY → HAVING). Реальный кейс: В аналитике продаж часто спрашивают: «Покажи клиентов, купивших больше чем на N рублей». Новички пишут WHERE SUM(amount) > N и получают ошибку. Правильный запрос с HAVING выполняется мгновенно, если есть индекс на client_id. Вывод для аналитика: WHERE — фильтрует строки до группировки. HAVING — фильтрует группы после агрегации. Запомните порядок: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY.

Бесплатный курс: веб-дизайн, графика, интерфейсы Получи востребованные навыки: - создание дизайна сайтов и приложений - создание инфографики и карточек для маркетплейсов - работа в графическом редакторе Figma и др. Студенты курса в среднем зарабатывают от 68 000 ₽ уже во время обучения💰 Зарегистрироваться #реклама 16+ ydaev.ru О рекламодателе

№4786 категория вопросов: #SQL

№4786 категория вопросов: #SQL

Есть только один правильный способ провести майские тот, что нравится вам. Выбирайте, где отдохнуть, и бронируйте отели, квартиры и загородные дома под себя на Яндекс Путешествиях со скидкой по промокоду MAYSKIE. 😊 Отдохнуть за городом 😊 Скататься в другой город 😊 Умчаться туда, где тепло Забронировать #реклама special.travel.yandex.ru О рекламодателе

☀Объяснение: Задача: оставить одну запись на (user_id, день) — самую раннюю по времени. Почему C — правильный? Оконная функция ROW_NUMBER() нумерует строки внутри группы (user_id, день) в порядке возрастания login_time. Самый ранний вход получает номер 1. Затем удаляются все строки с номером больше 1 (rn > 1). Это стандартный, производительный и надёжный способ дедупликации, поддерживаемый всеми современными СУБД (PostgreSQL, MySQL 8+, SQL Server, Oracle). Пример реального кода (вариант C): ```sql WITH ranked AS ( SELECT id, user_id, login_time, ROW_NUMBER() OVER ( PARTITION BY user_id, DATE(login_time) ORDER BY login_time ) AS rn FROM user_logins ) DELETE FROM user_logins WHERE (user_id, login_time) IN ( SELECT user_id, login_time FROM ranked WHERE rn > 1 ); ``` Почему не подходят другие варианты: A (NOT IN MIN(id)) — предполагает, что минимальный id соответствует самому раннему времени, но это не гарантировано (id может быть сгенерирован позже). Также NOT IN с подзапросом опасен при NULL и медленен на больших таблицах. B (JOIN по времени) — может случайно удалить и самую раннюю запись, если существует более ранняя в тот же день. Синтаксис не универсален. D (подзапрос > MIN) — некорректный синтаксис для массового удаления, выполняется построчно, очень медленно. Реальный кейс: В системе логов из-за ретраев образовались дубликаты: один пользователь в одну секунду имел несколько записей. Аналитик написал запрос с ROW_NUMBER() и удалил 8 млн дубликатов за 1 секунду. Вариант с NOT IN упал по таймауту. Вывод для аналитика: ROW_NUMBER() — ключевой инструмент для дедупликации, выбора первой/последней записи в группе. Это must-have в арсенале аналитика, работающего с SQL. 🎯 #SQL

Открываем выгодную Турцию Планирование отпуска — это не 48 открытых вкладок и путаница. Это только одна, с Яндекс Путешествиями. Сервис составил интерактивные карты с местами, до которых обычно не доезжают, чтобы вы могли по-новому раскрыть страну. Исследуйте Турцию и бронируйте отели с выгодой: — TURKEY5K скинет 5000 ₽ при бронировании от 50 000 ₽ — TURKEY10K скинет 10 000 ₽ при бронировании от 100 000 ₽ Забронировать #реклама special.travel.yandex.ru О рекламодателе

№4785 категория вопросов: #SQL

Яндекс Музыка до 360 дней бесплатно Яндекс Музыка для вас и 3-х ваших близких. Кинопоиск и Яндекс Книги тоже в подписке. Попробуйте бесплатно❤️ Слушать #реклама 18+ music.yandex.ru О рекламодателе

☀Объяснение: Суть проблемы Вы запускаете отчётный запрос, который выполняется несколько секунд. Пока он работает, другой процесс вставляет новые заказы. При уровне изоляции READ COMMITTED ваш запрос видит только те данные, которые были зафиксированы на момент начала чтения каждой строки, но из-за того, что вставки происходят параллельно, при повторном запуске того же запроса могут появиться новые строки (фантомы). Это называется фантомное чтение. Что такое уровень изоляции SERIALIZABLE? Самый строгий уровень изоляции транзакций. Он гарантирует, что параллельные транзакции выполняются так, как если бы они шли последовательно (одна за другой). Предотвращает все аномалии: грязное чтение, неповторяемое чтение и фантомы. В вашем случае: транзакция с отчётом при старте как бы «замораживает» состояние базы, и даже если другие транзакции вставляют новые строки, они не будут видны до конца текущей транзакции. Повторный запуск того же запроса в новой транзакции увидит изменения, но внутри одной транзакции результат будет стабильным. ❌ Почему не подходят другие варианты: A (READ UNCOMMITTED) — разрешает грязное чтение (видны незафиксированные изменения), вообще не решает проблему. B (READ COMMITTED) — предотвращает грязное чтение, но допускает неповторяемое чтение и фантомы. C (REPEATABLE READ) — предотвращает неповторяемое чтение (те же строки не меняются), но некоторые СУБД (например, PostgreSQL) на этом уровне не предотвращают фантомы, если не используется SERIALIZABLE. В MySQL с InnoDB REPEATABLE READ предотвращает фантомы благодаря gap-блокировкам, но это особенность реализации. Стандарт SQL предписывает предотвращение фантомов только на уровне SERIALIZABLE. Реальный кейс В системе аналитики отчёты формировались на уровне изоляции READ COMMITTED. Бухгалтер запускал отчёт по выручке, смотрел цифры, через 5 минут перезапускал — сумма менялась на несколько тысяч. Причина: параллельно шли начисления бонусов и новые заказы. Переключили отчётные транзакции на SERIALIZABLE — результат стал стабильным в рамках сессии, но производительность упала из-за блокировок. Компромисс: пошли на ежечасное обновление материализованного представления вместо реального времени. Что должен зафиксировать аналитик: Для отчётов, требующих строгой согласованности (финансы, аудит) — указывать требование к уровню изоляции SERIALIZABLE или использовать механизм снэпшотов (MVCC). Допустимость времени выполнения — SERIALIZABLE может быть медленнее из-за блокировок. Альтернатива: выполнять отчёты на реплике в режиме READ ONLY с уровнем SERIALIZABLE или делать снимок данных (экспорт) на момент начала формирования отчёта. Вывод: Выбор уровня изоляции влияет на согласованность и производительность. Аналитик должен требовать спецификации уровня изоляции для критичных отчётов, особенно в финансовой сфере. 🎯 #DBMS

Как автоматизировать рутину и контролировать процессы? Битрикс24 CRM. В одном продукте уже есть чаты, задачи, нейросеть, приём платежей и интеграция с 1С. Вся информация о клиентах и сделках хранится в единой базе, доступной с любого устройства. Руководитель видит отчёты, менеджеры экономят время на рутине, маркетологи получают данные для анализа. Для любого числа сотрудников. Начните с бесплатного тарифа. Зарегистрироваться #реклама 16+ bitrix24.ru О рекламодателе