Комментарии 25
В задаче с треками у вас в тестовых данных не было продаж за 2020+ года?
Вот такой запрос отработал 3 из 4 тестов на конкурсе, либо я не вижу какого-то существенного отличия, либо даты как-то неправильно сравниваю:
select Track.TrackId, sum(il.Quantity) as 'purchases'
from Track
inner join InvoiceLine IL on Track.TrackId = IL.TrackId
inner join Invoice I on I.InvoiceId = IL.InvoiceId
where InvoiceDate >= '2010-01-01'
group by Track.TrackId
order by purchases desc, Track.TrackId;
Вот проводили раньше на Яндекс.Контесте и Кодфорсе - проблем с платформой не было таких, как в этот раз. Но благодаря задаче "Анализ продаж" я теперь знаю что Employee (работник, служащий или рабочий по найму) - это на самом деле таблица продавцов на маркетплейсе =) В остальном, спасибо, было интересно!
Условие Invoice.InvoiceDate LIKE '201%' неверное, т.к. скрипт не учитывает 2020 год, но при этом учитывает 20100 год. Верно будет указать условие strftime('%Y',Invoice.InvoiceDate)>='2010' Здесь по правилу лексикографической сортировки все будет корректно не только до 2020 года, но и после него.
Писал в поддержку, но ни смотря на это решение не учли. Вот скрипт, который засылал, но он не прошел проверку.
select track.TrackId,sum(InvoiceLine.Quantity ) as cnt
from Track
inner join InvoiceLine
ON Track.TrackId = InvoiceLine.TrackId
inner join Invoice
on InvoiceLine.InvoiceId = Invoice.InvoiceId
where strftime('%Y',Invoice.InvoiceDate)>='2010'
group by Track.TrackId
order by 1,2 desc
В задаче данных позже 2015 года не было.
Таким образом оба варианта условия, приведенных вами, должны привести к одинаковому результату. Возможно ошибка в прохождении теста была в чем-то другом.
Можно будет позже попробовать самостоятельно доработать решение, чтобы оно проходило все тесты по условиям задачи. Потому что пользователи, кто решили задачу, есть.
А если я Вам скажу, что в первом задании по SQL правильное решение, которое вы сейчас указали в решении не принялось, но при подборе чекер принял решение, которое не соответствует требованиям, Вы согласитесь пересмотреть результаты?
По поводу комментария о том, что в тестовых данных не было данных старше 2015 года - это уже странно. Мы же не видели данных, на которых проводились тесты.
Очень спорные задачи и решения. По многим задачам при прочих равных условиях с опубликованными решениями система не выдавала максимальный балл, а то и вообще выдавало 0 баллов.
В двух последних задачах требуется рассмотреть строки с 2010 года. Адекватным кажется фильтрация уровня where year >= 2010. Авторы же делают LIKE '201%'. Под такую фильтрацию, как минимум, не попадут строки 2020 года и позднее, хотя они требуются условиями.
Задача с баллами, одно из 12 моих решений:
#!/bin/bash
read di1 di2
d1=$(date -jf %Y-%m-%d "$di1" +%s)
d2=$(date -jf %Y-%m-%d "$di2" +%s)
r=$(( (d2 - d1) / 86400 ))
if [[ "$r" < 0 ]]; then
r=$(( -r ))
fi
echo "$r"В чем решение не верно? Оно тянет на 0 баллов? 11 других решений тоже полностью удовлетворяют условию, но тоже 0 баллов!
Ваше решение работает под MacOS, но не работает под Linux. Про различия в синтаксисе команды date в разных ОС можно почитать, например, тут: https://www.shell-tips.com/linux/how-to-format-date-and-time-in-linux-macos-and-bash/#what-are-the-differences-between-linux-and-unixmacos&gsc.tab=0
С коллегами по sql выше полностью солидарен, все решения при сравнении типа поля DATETIME а не строки по LIKE (что уже выглядит очень глупо) получили 30 из 40 баллов. Что тут не так?
По всей видимости, данные решения даны с поправкой на заявления Сергея Ивлиева, перед контестом, цитата: Во время контеста мы смотрим не на качество кода, корректное использование конструкций, а только на то, как он решает поставленную задачу и с какой скоростью;
Это правильно, так происходит в любом контесте в том числе самого высокого международного уровня, где рез-т работы оценивается в итоге по сводной таблице автоматической системы тестирования (ваш код никто не смотрит). Качество кода оценивает тестирующая система - в этом плане суть этой проверки лежит на качестве тестов.
Другое дело формулировка некоторых задач. Например, "Напишите запрос, который будет искать трех продавцов на маркетплейсе, совершивших больше всего продаж, начиная с 2010 года." - неясно что надо: больше всего продаж в рублях или по колчеству сделок-продаж? Чтобы ответить на этот вопрос, надо было отправлять неверную гипотезу в систему.
Или в задаче "Маршруты" не были указаны ограничения входных данных. Да, это сейчас они указаны, но тогда их не было: Ограничения: 2 < n < 10^18, 1 <= r < 10^7
Или в этой же задаче, например: "В первую строку вводится одно целое число P(1<=R<=100)..."
Что за R? Понятно, что это опечатка, но осадочек остался.
Непонятно какую асимптотику ожидает автор задачи.
Но контест, все равно был достаточно легкий и эпичный (в плане сбоев).
Отмечу как минус - было слишком мало задач: по 2 задачи go/sql маловато, имхо.
В задаче «Анализ продаж» предлагается решение с группировкой по значению
Employee.FirstName || ' ' || Employee.LastName as Name
Разве это верно? Среди продавцов могут быть сотрудники с одинаковыми именем и фамилией.
Задача "Треки".
В условии:
В первой колонке должны быть Id трека, отсортированные в порядке возрастания, а во второй колонке - количество проданных копий трека, отсортированных в порядке убывания.
В решении:
ORDER BY Total DESC, TrackId ASC
Можете прокомментировать, как из этого условия следует, что данные необходимо сначала сортировать по количеству проданных копий?
На мой взгляд, из условия следует, что сортировать нужно сначала по Id трека (и далее какая-то сортировка теряет смысл, так как это первичный ключ, по которому группируем записи).
Конечно, в начале задачи сказано "Напишите запрос, который составит рейтинг треков по их продаваемости", но дальнейшие формулировки затрудняют понимание =(.
Задача «Треки».
Решение вида:
SELECT TrackId, SUM(Quantity) as total FROM InvoiceLine il
JOIN Invoice i ON i.InvoiceId = il.InvoiceId
WHERE strftime('%Y', i.InvoiceDate) >= '2010'
GROUP BY TrackId ORDER BY total DESC, TrackId ASCпроходило ровно половину тестов, что с ним не так, я не смог разобраться...
Задачи интересные, но я так и не понял что в них специфического для Go-разработчиков?
Маски, картины, тайные покупатели и анализ продаж: разбираем решения задач для Go-разработчиков