Как стать автором
Обновить

Маски, картины, тайные покупатели и анализ продаж: разбираем решения задач для Go-разработчиков

Время на прочтение10 мин
Количество просмотров12K
Всего голосов 16: ↑13 и ↓3+23
Комментарии25

Комментарии 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;

Нет, самые поздние даты в тестовых данных относились к 2015 году

Касательно второго вопроса напрямую проконсультировать не сможем. Можно будет позже прорешать эту задачу самостоятельно и прийти к решению, которое проходит все 4 теста.

А когда планируется открыть доступ к тестированию снова?

В ближайшее время, нужно подождать анонса :)

Вот проводили раньше на Яндекс.Контесте и Кодфорсе - проблем с платформой не было таких, как в этот раз. Но благодаря задаче "Анализ продаж" я теперь знаю что 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 года и позднее, хотя они требуются условиями.

Да, мы уже выше ответили по другим комментариям.

В таблице не было данных старше 2015 года, поэтому это решение также проходит тесты.

Задача с баллами, одно из 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-разработчиков?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий