SQL — удалённая работа в Москве

Доработать существующую базу данных. Работаю программистом Java/C# Суть задачи: Есть функция на PostgreSQL. Она возвращает примерно 30к записей. В теле функции есть несколько select запросов к разным таблицам. Так там есть join и union. Работает около 5-6 минут. Выгрузить эти записи на бэк сразу всем скопом нельзя, т.к получаем таймаут. Поэтому на бэк записи выгружаются блоками. При очередной выгрузке нового блока идёт снова и снова обращение к вышеупомянутой функции. Вследствие чего, отчёт, для которого нужны записи, строится оооочень долго. Нужна помощь, как можно оптимизировать этот функционал. Со своей стороны смогу предоставить только демонстрацию экрана. Полный код отправить не смогу.

Помощь при устройстве и поиске работы. Нужен опытный ментор для помощи устроиться на работу или стажировку. Что нужно ещё: поддержка и сопровождение.

Выполнить задание. Выполнить задание.

алгоритм распределения. Бизнес-задача: распределить взаимную проверку студентами заданий. Все на SQL. На Supabase будет выполняться (есть особенности). На вход функции: sprint_strapi_document_id (идентификатор учебной недели) Ожидаемый результат: По 3 заданиям, привязанным к учебной неделе проведены распределения студентов с соблюдением ряда условий. Подробнее: ЧТО ДЕЛАЕТ ГЕНЕРАТОР (ПРИМЕРНО) 1. Старт Получает идентификатор спринта и режим работы («затереть всё» или «дописать недостающее»). Спринт = учебная неделя. 2. Очистка (по желанию) Если запрошен «затереть всё» — удаляет из результата всё, что относится к этому спринту, и фиксирует, сколько строк исчезло. 3. Снимок входных данных Собирает четыре набора сведений, без хранения в БД: 1. перечень дуэлей (2 пользователя делают одну задачу) спринта и их тип (тренировочная / боевые); 2. список разрешённых участников (не уволены, из нужного потока); 3. для каждой сыгранной пары — самые свежие ответы обоих игроков — у каждого ответа есть pair_id; 4. из предыдущего пункта формирует сами пары: «идентификатор пары + оба игрока». 4. Рассчитывает квоты Для каждого допущенного пользователя считает: сколько он сыграл ответов × 3 — столько он обязан проверить. У кого получилось 0 — тот сразу «вне игры» (ему нечего проверять, он никому не нужен). 5. Готовит «кольца» – два воображаемых циклических списка Первое кольцо: шесть «слотов» подряд для каждого будущего рецензента. Второе кольцо: шесть «слотов» подряд для каждой пары, которую надо проверять. 6. Базовый round-robin 1. Для тренировочных дуэлей всем парам заранее выбирает «сдвиг» — на сколько позиций провернуть кольцо рецензентов. Для боевых дуэлей сдвиг 0. 2. «Накладывает» кольцо рецензентов на кольцо пар с учётом сдвига и тем самым назначает первых шесть рецензентов каждой паре, игнорируя случаи «рецензент = игрок пары». Получается черновой чертёж назначений. 3. Из квоты каждого назначенного рецензента вычитает израсходованные слоты. 7. Дозакрывает пары, где оказалось меньше 6 рецензентов Пока остаются «дыры»: • выбирает кандидатов с ещё не обнулённым лимитом, которых нет в данной паре и которые не столкнутся с ограничениями; • назначает их, строго не превышая «осталось проверить» ни у пары, ни у кандидата; • обновляет, сколько ещё нужно и какие квоты остались. 8. Сохраняет результат Каждое назначение дублирует на обе записи пары (чтобы вышло ровно 12 строк на пару: 6 рецензентов × 2 игрока). Старые строки не дублируются — если они уже существуют, пропускает. 9. Проверяет себя Есть две жёсткие проверки — если хотя бы одна не пройдена, всё откатывается и бросается исключение: 1. у каждой пары должно быть ровно 6 назначений, иначе фиксируется список «неполных» пар (попадают в лог) и генератор падает; 2. ни у одного рецензента фактическое число назначений не может превышать рассчитанную квоту; нарушители фиксируются в отдельный список и тоже приводят к падению. 10. Формирует отчёт Возвращает JSON: • уникальный идентификатор запуска; • статус «OK» или «ERROR»; • массив шагов-сообщений в хронологическом порядке: сколько строк стерто, сколько сохранено, попали ли пары в «неполные», есть ли «перебранные» квоты, прошла ли финальная валидация. Полный набор логических «баз»,-которыми оперирует генератор (ниже — только смысловая структура: названия полей и связь с алгоритмом; никаких SQL-таблиц или DDL-врезок) 1. Пользователи • user_id – внутренний идентификатор участника • stream_id – учебный поток (курс) • team_id – команда внутри потока • dismissed_at – дата отчисления / увольнения или пусто Зачем нужно → позволяет • убрать выбывших, • узнать команду игрока для правил FULL-CONTACT, • связать участника с потоком спринта. 2. Страйки • user_id – кто получил штраф • sprint_id – за какой спринт штраф Зачем нужно → если есть запись по текущему спринту, пользователь не допускается к проверкам. 3. Потоки и Спринты • stream_id ↔ sprint_id – один поток может иметь несколько спринтов Зачем нужно → определить, каких пользователей считать «своими» для данного спринта. 4. Команды • team_id – идентификатор команды • stream_id – чей поток Зачем нужно → различать «свою» и «чужую» команду в боевых дуэлях. 5. Дуэли • duel_id – внутренняя ссылка в ответах • sprint_id – к какому спринту относится • type – TRAINING или FULL-CONTACT Зачем нужно → отфильтровать дуэли спринта и понять, нужны ли правила баланса команд. 6. Ответы на дуэли • pair_id – уникальный идентификатор пары игроков • user_id – автор конкретного ответа • rival_id – соперник автора • duel_id – какая дуэль • hash – общий «ключ партии» (одинаков у двух строк пары) • created_at – когда отправлен ответ Зачем нужно → • брать самый свежий ответ каждого игрока в паре, • посчитать, сколько ответов сыграл каждый пользователь → сколько рецензий он обязан выдать (квота = 3 × ответы), • сформировать список всех пар «hash + duel». 7. Назначения на проверку (целевая таблица) • reviewer_id – кто будет проверять • duel_id – дуэль пары • user_id – чей ответ проверяется • hash – «ключ партии» (чтобы различать пары) Зачем нужно → конечный результат работы генератора; строка уникальна в сочетании (reviewer_id, hash, duel_id). 8. Внутренние счётчики-выкладки генератора. Что нужно ещё: поддержка и сопровождение, разработать документацию. Если сработаемся — есть много задач на стэке Supabase/Bubble/N8N.

Выполнить тест. Задание на проверку базовых навыков SQL (для экономистов).

Добавить LM заказы в дэшборд с помощью кода sql. Доработка существующего продукта. Нужно добавить существующий код SQL в джшборд(LM) Сейчас его перевели на обновление раз в 10 минут и сообщают что это многое исправит в его работоспособности. Нужно собрать код по частям(готовый) и заново внедрить, видео объясняющие задачи доп есть(возможно совместное выполнение задачи) Просьба добавить LM заказы в дашборд Все данные, код предоставлю, возможна доработка кода. Хороший навык писания кода sql, хорошее умение ориентироваться в незнакомых бд и дэшбордах.