SQL-разработчики в Белгороде

Разработать базу данных с нуля.

Добрый вечер, необходимо разработать базу данных "автоматическая система учёта успеваемости студента" к заданию прикрепляю для примера готовую работу "автоматическую систему учёта и хранения курсовых работ студентов".

Нужена будет база данных и скриншот

Для работы

Обучить основам.

Для сдачи зачета необходимо обучение основам, на примере конкретных заданий

Подготовка к экзамену.

До экзамена 1,5 месяца, нулевой вариант экзамена могу прислать в личном сообщении. Основные темы: проектирование базы данных в 3 нормальной форме, представление (с джоинами), хранимая процедура с транзакцией и триггер. Нужна помощь с подготовкой

20 лет. Подготовка к экзамену

Доработать существующую базу данных.

Работаю программистом Java/C#

Суть задачи:

Есть функция на PostgreSQL.

Она возвращает примерно 30к записей. В теле функции есть несколько select запросов к разным таблицам. Так там есть join и union.

Работает около 5-6 минут.

Выгрузить эти записи на бэк сразу всем скопом нельзя, т.к получаем таймаут.

Поэтому на бэк записи выгружаются блоками. При очередной выгрузке нового блока идёт снова и снова обращение к вышеупомянутой функции.

Вследствие чего, отчёт, для которого нужны записи, строится оооочень долго.

Нужна помощь, как можно оптимизировать этот функционал.

Со своей стороны смогу предоставить только демонстрацию экрана. Полный код отправить не смогу

Помощь с подготовкой к демоэкзамену(простому).

Здравствуйте! Нужна помощь с подготовкой к демоэкзамену, могу расписать в тг все, если хотите. Также там и скинуть пробные варианты демоэкзамена. Он, как я понимаю, достаточно простой.

Что нужно ещё: Создать базу данных, импортировать данные итп

Помощь при устройстве и поиске работы.

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

Что нужно ещё: поддержка и сопровождение

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

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

Создать скрипт для выгрузки данных по всем имеющим юр лицам, у которых есть вид деятельностиых с вложения.

Создать скрипт.

Что нужно ещё: поддержка и сопровождение

Разработать базу данных с нуля.

Создание базы данных в MySQL или PostgreSQL:

- 3 основных блока (продукты, поставщики, заказчики).

- Объем данных относительно небольшое (несколько десятков продуктовых листов (по 50-60 продуктов), поставщиков и заказчиков).

- Обеспечить возможность удобной выборки продуктов из блока Product в соответствии с заданными критериями

- Иметь возможность формировать отчеты по основным срезам (например продукты определенной категории). А также иметь возможность позже создавать новые форматы отчетов.

- Итого 2-3 пользователя, с возможностью одновременной работы с базой. Вход в базу данных по паролю

- Создание интерфейса для администрирования.

Что нужно ещё: разработать пользовательский интерфейс, провести инструктаж и обучить пользователей.

В приложении описание архитектуры БД

Разработать базу данных с нуля.

Нужна простейшая база данных для магазина музыкальных инструментов, разарботанная в Microsoft SQL Server Tools с интерфейсом в Visual Studio C#.

Что нужно ещё: разработать пользовательский интерфейс, интегрировать базу данных с другими системами.

Магазин с не сложной системой. Нужны Таблица Сотрудники,

Таблица Клиенты,

Таблица Товары,

Склад в котрый заказываются и из которого заказываются товары,

Общая таблица продажи связывающая остальные, заказы и

Отчёт по продажам. Триггеры и хранимые процедуры по случаю

Квалификационная работа.

Сделать задания из прикреплённом файла для выпускной квалификационной работы по направлению Анализ больших данных

Разобрать задания.

Помочь разобраться с заданиями в университете.

Что нужно ещё: провести инструктаж и обучить пользователей

Разработать базу данных с нуля.

Необходима помощь с созданием бд по финальному заданию обучения.

Что нужно ещё: Только помощь

Прохожу курс, помочь с одной темой.

Прохожу курс, помочь с одной темой

Подготовка к экзамену.

До экзамена 1,5 месяца, нулевой вариант экзамена могу прислать в личном сообщении. Основные темы: проектирование базы данных в 3 нормальной форме, представление (с джоинами), хранимая процедура с транзакцией и триггер. Нужна помощь с подготовкой

Алгоритм распределения.

Бизнес-задача: распределить взаимную проверку студентами заданий.

Все на 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