Тестовое задание - помогите выполнить, Прислали мне тестовое задание

inpost

Вот с этим я категорически не согласен. Даже у нас на форуме есть несколько человек, которые совершенно неспособны решать простые задачи просто. Именно потому, что умеют их решать сложно. Как в анекдоте про двух новых русских - я галстук за 100 баксов купил! Идиот, там за углом точно такие же за 150 продаются!

Твоя ошибка в том, что ты решаешь задачу однобоко. Ты представляешь себе сайт Приват Банка с миллионной посещаемостью, который почему то расположен на шареде. И пытаешься экономить ресурс, которого у Приват Банка более чем достаточно, за счет усложнения программы.

А высокие нагрузки в первую очередь требуют простоты обслуживания: любая секунда в устранении неполадки или модификации кода грозит реальными потерями клиентуры и денег в конечном итоге.

Если требуется получить конкретный результат, нужно просто его получить. Если на это не хватает ресурса, только тогда нужно пытаться что-либо оптимизировать. Так как миллион записей за 5 лет, это полный пшик для хорошего сервера. Такой пшик, что ни о каком кэшировании не возникает даже мыслей.

Так что будь я на месте работодателя, я бы крепко задумался - нужен ли такой человек, который из каждой мухи будет раздувать большого и неповоротливого слона, которого трудно читать, исправлять и обслуживать.

Ибо любое усложнение программы прямо пропорционально количеству возможных багов и обратно пропорционально гибкости решения.

UPD И кроме того, показать умение писать запросы, которые удовлетворяют условиям задачи, это значит показать свою квалификацию. А решить задачу одним селектом, сочинив до этого огромадную прокладку, похоже на умение лепить костыли, прикрывая свою несостоятельность в SQL фиговым листком заботы о ресурсах.

Непонятно зачем пытаться так грубо обманывать и перекручивать?
Или ты считаешь что тут все тупые собрались, которых можно так дешево обмануть?
SQL-запрос - это вообще любая выборка без разницы есть в ней подзапросы или нет, или соединения...
Тут между прочим простой подзапрос с подстановкой данных и я когда то читал что для mysql такие подзапросы предпочтительней джойнов.

И да, вот ты сам, давая например своему помощнику четкую задачку как в этой теме на составление sql запроса неужели хотел бы получить от него не нужный тебе запрос, а какую то постороннюю философию про какое то кеширование? С последующими за этим спорами, разногласиями и соответствующей этому потерей времени.

Ну насколько я знаю запрос с UNION обрабатывается практически как два (или n) разных запроса, без учета времени на траффик между серверами, обработка всего остального настолько сложна, что наверно уже сами разработчики иногда удивляются как так
Естественно иногда скорость запроса зависит от грамотного расположения подзапросов, но для этого и нужно "курить SQL", чтобы не нагружать лишней работой СУРБД.
В результате дискуссии в данной теме мы получили 2 разных запроса, какой из них лучше можно определить только с помощью тестов, причем желательно на реальной базе в десятки миллионов строк, хотя сильно сомневаюсь, что в реальном приложении устаревшие данные не будут удалятся из таблицы, но тут речь об эффективности запроса.

Ну насколько я знаю запрос с UNION обрабатывается практически как два (или n) разных запроса,

Каким боком к моему высказыванию UNION приплетен вообще?...

Вы что считаете что оператор SELECT это и есть именно SQL запрос, а остальное - что то другое?
INSERT ... - это тоже SQL запрос.

Michael, вы не поняли. Просто речь со стороны inpost шла о том что запрос с подзапросом - это два запроса. Нет это не так. И только запрос содержащий UNION можно теоретически рассматривать, как два отдельных запроса. Там сервер отдельно обрабатывает каждый запрос и лишь потом соединяет результат.

twin
Несколько раз подчеркнули "усложнение", хотя разбить на 2 запроса гораздо проще в итоге как в понимании кода, так в его редактировании. 10 минут на код, а раздули из этого слона. Почему 10 минут кода = сложно?

Я бы не был так в этом уверен.
Когда на сервер поступает sql запрос, сервер составляет план выполнения запроса.
И уже его потом выполняет.
Это кстати причина почему рекомендуют использовать подготовленные запросы - ранее составленный план не составляется заново.
И этот план оптимизируется насколько возможно.

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

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

Дамп:

Свернутый текст

CREATE TABLE IF NOT EXISTS `data` (
  `data` date NOT NULL,
  `currency` varchar(10) NOT NULL,
  `rate` decimal(10,2) NOT NULL,
  UNIQUE KEY `ind1` (`currency`,`data`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

--
-- Дамп данных таблицы `data`
--

INSERT INTO `data` (`data`, `currency`, `rate`) VALUES
('2012-01-01', 'EUR', 40.10),
('2012-01-02', 'EUR', 40.60),
('2012-01-03', 'EUR', 40.30),
('2012-01-01', 'USD', 30.10),
('2012-01-02', 'USD', 29.70),
('2012-01-03', 'USD', 29.90),
('2012-01-31', 'USD', 30.00),
('2012-02-01', 'USD', 29.00);

Запрос:

SELECT *
FROM DATA 
WHERE (currency,DATA)
  IN (
    SELECT currency, MAX(DATA)
    FROM DATA
    GROUP BY currency
  )

Результат:

 	data 	currency 	rate
	2012-01-03 	EUR 	40.30
	2012-02-01 	USD 	29.00

inpost

Да, всё верно. Два простых запроса лучше чем один сложный.

Но сама концепция решения сей задачи не верна.

Вот смотри. Можно перевести бабушку через дорогу. Взять и перевести.

А можно попытаться в этом месте нарисовать зебру.

Да. Зебра для бабушки круче. Но. Она одна же... Но может еще две-три. А движение большое. Стоит ли бодаться с ветрянными мельницами в виде гаи, дорожников, депутатов, демократов, и хрен пойми кого, чтобы перевести одну бабушку через дорогу?

Проще же взять её за руку и перевести. Пусть это немного опаснее для тебя. Но завтра будет другая в другом месте.

Программист должен думать и за бабушку, и за бестолковое ГАИ, и за... Да за всё.

Крутое решение не есть крутое со всех сторон. Кэш - круто конечно. Но не до фанатизма же.

twin
такой запрос с подзапросом с группировкой - тяжелое дело, не вижу фанатизма.

Давай я опишу данную ситуацию. Ты стоишь в 10 метрах от зебры, и бабушка просит перевести через дорогу. Можно прямо пойти и создать множество рисков, а можно пройтись 10 метров до зебры, потратив на это несколько минут и уже после перевести через зебру, теперь нет ни нарушений, и безопасно, всё сделано правильно, а потратишь всего навсего несколько лишних минут, которых у каждого человека в изобилии.

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

Это сообщение отредактировал inpost - 12.01.2013 - 01:07

Во как)))

Я вот вчера приехал из Вьетнама. Движение там пипец, я напишу отчет скоро о поездке.
Там есть зебры, но им они пофиг. И знаешь почему? Потому что маленький мотобайк труднее остановить, чем остановится пешеходу. А объехать им легче.


Так вот. Если можно объехать, нужно объехать. Не нужно останавливаться и подножку высовывать.

Так и тут. Если можно получить результат, нужно его получить, я уже писал. А не разбивать на 2 запроса с промежуточными вычислениям и т.д.

Для понимания может и да. Я сам часто ругаюсь на неоправдонное усложнение. Но не всегда, черт побери.

Да потому что 10 минут твоего решения оборачиваются в 100500 минут тех, кто читает потом.

А самое главное, ответь. ЗАЧЕМ?
Кэшировать то, что по определению должно храниться в базе (для того она и) на мой ИМХО взгляд - клаустрофобия как минимум, непонимание SQL как максимум. Прости.

twin
Опять же, кто читает, единственный аргумент. А зачем мне делать проекты, которые завтра будут поддерживаться другими людьми? Может ты как начальник хочешь, чтобы внутри твоей рабочей группы ты мог передавать проекты от одного подчиненного к другому, вот только зачем лаконичным и удобным его делать для посторонних глаз?

А кто сказал, что я избежал хранения данных в базе? Я распределил нагрузку между SELECT и INSERT, в то время когда как эти 2 понятия в БД являются взаимозамещающими. И тут о скорости не шло речи, тут идёт о реализации, я выбрал мою реализацию, кто-то выбрал другую реализацию, оба выполнили поставленные цели, но моя реализация работает быстрее.

Ещё раз, завтра ты заплатишь свои 1`000$ за проект программистам, оба программиста выполнят программу за один и тот же срок, тебе осталось лишь заплатить одному из них, так как ты проводил тендер, и заплатишь тому, чей код работает быстрее, а не чей код красивее, потому что сайт делается для посетителей, а не для других программистов. Так вот в итоге по тендеру выиграю я, и не надо спорить по этому поводу.
Мы имеем прямую, в которой с одной стороны стоит удобство для программиста (радость программиста), с другой стороны скорость для клиента (радость клиента). Мой выбор сделать так, чтобы клиент был доволен, а не другие программисты. Ты своей фразой сейчас уподобаешься CMS-щикам, которые на джумле штампуют сайты не задумываясь об эффективности кода.

ужас 1

ужас 2

странно

есть поговорка: не всегда самый короткий путь есть еще и самый быстрый. Код пигется 1 (один) раз, а читается 10 (десять).


пардон конечно...

waldicom
Игнорирую тебя обычно, но тут отпишусь, надеюсь срача не будет хотя бы в этой теме:
"странно"? Разве? Человеку было слишком смешно, я убрал улыбку тем, что показал, что с моей реализации не надо улыбаться, потому что она такая же, как и обычная реализация, которая имеет и свои плюсы и свои минусы. В реальном проекте не будет такого запроса с подзапросом и группировкой, а вот мой код может быть, потому что в моей реализации я дал конечный продукт для любого сайта, а тот запрос будет лишь кусок общей реализации, которую ещё надо допиливать. Кто-то в итоге запихнёт в файловый кеш, если свой сервак, киданул в мем-кеш, зачем каждый раз дёргать mysql для главной страницы?!