Комментарии 35
НЛО прилетело и опубликовало эту надпись здесь
Ой. Это нездоровый практицизм. Я с таким подходом даже боюсь интересоваться Вашим мнением по поводу школьных задач и упражнений. Они к реальной жизни вообще никак не прикладываются. Все экзотерические языки, коих зачем-то понапридумывали десятки, если не сотни, — тоже почему-то не нацелены на практический результат. Ну и так далее, могу привести ещё примеров. Так вот при изучении новой для себя области знаний нужны задачи, которые не важно насколько востребованы. Они нужны, чтобы понять и усвоить новые знания. Осознать, что новый инструмент может, а чего не может. Молоток во время освоения не помешает попробовать и на зуб. А уж для программистов игры чистого разума важны как ни для какой другой специальности, головные ганглии тренировать.
А уж о сути реляционных БД я готов с Вами поспорить. Начиная с быстрой обработки (далеко не всегда) сложноструктурированных (зачем же непременно «сложно»?) и до большого объёма. Вот, например, самая распространённая БД на нашей планете — SQLite — отнюдь в большие объёмы не просится, скоростью упирается в железо, на котором работает, сложностью структур обычно тоже не может похвастаться. Но вот удобство работы с данными и хороший запас неубиваемости — и все чайники, микроволновки и пылесосы используют. Ну и смартфоны конечно тоже.
А уж о сути реляционных БД я готов с Вами поспорить. Начиная с быстрой обработки (далеко не всегда) сложноструктурированных (зачем же непременно «сложно»?) и до большого объёма. Вот, например, самая распространённая БД на нашей планете — SQLite — отнюдь в большие объёмы не просится, скоростью упирается в железо, на котором работает, сложностью структур обычно тоже не может похвастаться. Но вот удобство работы с данными и хороший запас неубиваемости — и все чайники, микроволновки и пылесосы используют. Ну и смартфоны конечно тоже.
НЛО прилетело и опубликовало эту надпись здесь
как можно проверить степень владения языком запросов по задачам на форматирование текста?
Нормально так можно, если для вышеозначенной обработки текста нужно владеть навыками построения рекурсивных запросов, группировкой и агрегацией данных, да ещё довольно витиевато совместить это всё несколько раз для получения результата. Не говоря уже о том, что декларативный способ решения задач на SQL сам по себе требует мысленных усилий. То есть не каждый владеющий техникой рекурсивных запросов и группировки данных сумеет задачу с генерацией календаря решить.
Для предложенной Вами задачи навыков нужно меньше, а сама задача проще.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
как можно проверить степень владения языком запросов по задачам на форматирование текста?
Нормально так можно, если для вышеозначенной обработки текста нужно владеть навыками построения рекурсивных запросов, группировкой и агрегацией данных, да ещё довольно витиевато совместить это всё несколько раз для получения результата.
Я думаю тут кроется проблема. SQL нам нужен не для рекурсивных запросов с группировкой и агрегацией, а для того, чтобы интерпретировать данные и получать из них информацию.
Поэтому и задача должна быть не "напиши запрос", а "выяви некий факт".
Поэтому и задача должна быть не «напиши запрос», а «выяви некий факт».Это будет задача на бизнес-логику, а не на знание SQL.
Это будет задача на бизнес-логику, а не на знание SQL.
Что от этого меняется? Постановка задачи может потребовать использования всех возможностей SQL для решения.
Это будет задача на бизнес-логику, а не на знание SQL
А потом мы скажем работодателю: мы тут запросы пишем, причём здесь задачи бизнеса? А он такой: "За прочтение должностной инструкции расписывался, да?"
Я, конечно, знал всегда, что олимпиадные задачи далеки от практики, но чтобы настолько — не представлял.
Для меня sql — прежде всего и больше всего система хранения и выборки данных, представленных в виде таблиц. А для внешнего вида есть другие средства.
В общем, такие задачи — цель ради достижения, нереально круто и совершенно непрактично. Наверное, я уже подрастерял детско-юношеский максимализм и дошёл до того возраста, когда пафос подобных достижений — ничто...
В общем, такие задачи — цель ради достижения, нереально круто и совершенно непрактично. Наверное, я уже подрастерял детско-юношеский максимализм и дошёл до того возраста, когда пафос подобных достижений — ничто...
Нет, Вы просто не под тем углом на эту задачу смотрите. Это олимпиадная, то есть в первую очередь учебная задача. Работодатель Вам такой задачи никогда не даст.
Да, я смотрю под тем углом, под которым учебная задача должна не только прокачивать мозг (это не плохо само по себе, но это не для меня уже), но и дать какое-то потенциально полезное умение. Учебная… Чему учебная? Если не рассматривать цель экстремального самовыражения (то есть отбросить голый спорт), то всё, что я вижу здесь — хардкорная смесь бизнес-логики (построение календаря) и представления (форматирование по столбцам) — то есть то, от чего лучше бы отучать.
Разве что для непосредственной загрузки данных в Эксель такой подход может хоть чем-то быть полезен.
Уважаемые Danik-ik, musicriffstudio, akryukov! Давайте я вам всем вместе отвечу и наконец закрою эту ветку дискуссии, которая относится к практичности данной задачи.
Эта задача была придумана и использована на втором заочном туре олимпиады по SQL, статью о которой я публиковал раньше. Там как раз объяснялось почему эти пять задач второго тура делались совершенно преднамеренно в стиле, который должен был вызвать у участников вопросы типа «О ужас, да разве такое вообще на SQL делается?!?» Практичность тут не только не была в более низких приоритетах, она вообще не рассматривалась. Если такой подход вызывает вопросы то надо было там это обсуждать, в той статье.
Тут же я дал разбор одной из тех задач. Если есть вопросы по разбору, что-то осталось непонятным, или есть пожелания, что рассмотреть ещё на темы, связанные с SQL, то прошу высказываться. Участвовать в дискуссии о практичности данной задачи, в которую я невольно вступил, я больше не хочу. В контексте того что тут рассматривается только решение, а не создание данной задачи, считаю эту дискуссию неуместной. А то приходят люди со стороны, видят что задача и в самом деле далека от практики, и не разобравшись лепят мне минусы ни за что ни про что, понижая мою мотивацию популяризировать SQL. Предлагаю поставить точку и останоиться. Спасибо.
Эта задача была придумана и использована на втором заочном туре олимпиады по SQL, статью о которой я публиковал раньше. Там как раз объяснялось почему эти пять задач второго тура делались совершенно преднамеренно в стиле, который должен был вызвать у участников вопросы типа «О ужас, да разве такое вообще на SQL делается?!?» Практичность тут не только не была в более низких приоритетах, она вообще не рассматривалась. Если такой подход вызывает вопросы то надо было там это обсуждать, в той статье.
Тут же я дал разбор одной из тех задач. Если есть вопросы по разбору, что-то осталось непонятным, или есть пожелания, что рассмотреть ещё на темы, связанные с SQL, то прошу высказываться. Участвовать в дискуссии о практичности данной задачи, в которую я невольно вступил, я больше не хочу. В контексте того что тут рассматривается только решение, а не создание данной задачи, считаю эту дискуссию неуместной. А то приходят люди со стороны, видят что задача и в самом деле далека от практики, и не разобравшись лепят мне минусы ни за что ни про что, понижая мою мотивацию популяризировать SQL. Предлагаю поставить точку и останоиться. Спасибо.
Знаете, тут нет никакой проблемы. SQL — это ЯП. Несколько специфический, но ЯП. Это инструмент. Если он подходит для решения задачи, то его можно использовать. Если есть более подходящий инструмент, то надо использовать более подходящий. Все вот эти комментарии вокруг, что SQL подходит для этого и не подходит для того, для меня звучат как анекдот про котов. Просто надо уметь готовить. Нам видите ли SQL не для группировки и агрегации (а для чего же ещё?), а C очевидно не для циклов. Рок против наркотиков, коты против сметаны. (голосом Иа-Иа) Ха-ха.
Конкретно рассмотренная задача берёт из БД год и размер календаря. Пример такой задачи — просмотр каких-нибудь календарных данных (отпусков, отключений горячей воды, дежурств, доступности каких-то ресурсов) в интерфейсе, который может настраиваться по ширине (десктоп и мобильный клиент или самостоятельно пользователем). Если у Вас будет именно такая задача, и лучше всего её будет решать на сервере, то подобного вида запрос как раз и сможет это делать. Хотя для реальной жизни конечно это слишком заумный запрос, поддерживать будет тяжело.
Конкретно рассмотренная задача берёт из БД год и размер календаря. Пример такой задачи — просмотр каких-нибудь календарных данных (отпусков, отключений горячей воды, дежурств, доступности каких-то ресурсов) в интерфейсе, который может настраиваться по ширине (десктоп и мобильный клиент или самостоятельно пользователем). Если у Вас будет именно такая задача, и лучше всего её будет решать на сервере, то подобного вида запрос как раз и сможет это делать. Хотя для реальной жизни конечно это слишком заумный запрос, поддерживать будет тяжело.
Вижу, что мне не удалось донести свою мысль вам.
Все вот эти комментарии вокруг, что SQL подходит для этого и не подходит для того, для меня звучат как анекдот про котов. Просто надо уметь готовить.
Я думаю, что это нормально что существуют задачи, для которых SQL не подходит. Как вы говорили "Это инструмент". А каждому инструменту — свое назначение. Генерация красивого календаря в интерфейсе, который настраивается для десктоп и мобильных экранов — задача для какого-нибудь фреймворка для фронтенда. Применять SQL для ее решения — нецелесообразно.
Нам видите ли SQL не для группировки и агрегации (а для чего же ещё?)
Группировка и агрегация — просто приемы, которые мы используем для решения каких-то прикладных задач. Топор нам не для того, чтобы бить по дереву, а придания деревянному бруску желаемой формы. Точно так же и SQL нам нужен не для выполнения запросов, а для извлечения информации из данных.
Если у Вас будет именно такая задача, и лучше всего её будет решать на сервере, то подобного вида запрос как раз и сможет это делать.
У SQL есть более распространенные способы применения, нежели "генерация красивой картинки в интерфейсе с динамической шириной". Я считаю, что и олимпиаду надо делать для более распространенных задач.
Я считаю, что и олимпиаду надо делать для более распространенных задач.Олимпиады в любой области, хоть по физике, хоть по математике, хоть по программированию предлагают нестандартные заковыристые задачи. Но почему-то именно для SQL вы требуете исключения. А в чем олимпиадность тогда?
Кроме того, вы явно не работали разработчиком БД. 99,(9)% практических задач настолько банальны, что максимум через год любые запросы можно писать, не включая мозг вообще.
Мозг бывает нужен в трех местах:
1) на этапе проектирования БД
2) заковыристые пожелания заказчика вроде предложенных здесь (раз в год в одном проекте из 10 получается так, что вот в данных конкретных условиях написать условный «календарь» проще всего именно на SQL)
3) очень большие базы, где надо писать запрос так, чтобы у него получился хороший план
Бывают еще всякие крайности, типа «профакапили этап проектирования». У меня жена как раз в таком стартапе работает, там какая-то хипстота налепила таблицы как бог на душу положит (я ее по SQL консультировал как раз). В итоге связанные по смыслу таблицы, которые по уму должны были бы быть связаны через foreign key (ну типа одна таблица — что купил пользователь, а вторая — сколько заплатил), не связаны вообще никак, из общих данных только ID клиента и дата покупки с округлением чуть ли не до дня. Ну да, можно сделать такую олимпиаду: вот вам через одно место спроектированная БД, сделайте к ней запрос, возвращающий конфетку.
Олимпиады в любой области, хоть по физике, хоть по математике, хоть по программированию предлагают нестандартные заковыристые задачи.
Я только "за" нестандартные заковыристые задачи. Но считаю, что сравнивать SQL и математику — некорректно. Это термины разных уровней абстракции. Вот если бы вы сравнили информатику с математикой или SQL с интегрированием, то я бы согласился.
Кроме того, вы явно не работали разработчиком БД. 99,(9)% практических задач настолько банальны, что максимум через год любые запросы можно писать, не включая мозг вообще.
В другой ветке комментариев я предлагал постановку достаточно сложной задачи, с которой приходится иметь дело.
3) очень большие базы, где надо писать запрос так, чтобы у него получился хороший план
Я думаю такая задача тоже достойна включения в олимпиаду. Правда она будет ориентирована на конкретный набор СУБД.
Ну да, можно сделать такую олимпиаду: вот вам через одно место спроектированная БД, сделайте к ней запрос, возвращающий конфетку.
На плохо спроектированной задаче будет уместно ставить задачу на перепроектирование и миграцию без потерь. Это ведь тоже заковыристая задача. Плюс она реальная и нужная. Было бы неплохо видеть подобные на олимпиадах.
На плохо спроектированной задаче будет уместно ставить задачу на перепроектирование и миграцию без потерь. Это ведь тоже заковыристая задача. Плюс она реальная и нужная.
Если уж речь о практике, то нужной задача становится ровно тогда, когда находится кто-то, готовый заплатить за её решение. Других критериев нужности я пока не встречал. (:
Было бы неплохо видеть подобные на олимпиадах
Кстати, в финале мы давали пару задач как раз на технику оптимизации.
Да не, Вашу мысль я понял ещё за долгие годы до сегодняшних дней. Каких только практических задач мне не попадалось в жизни.
Ну вот вам бизнес-задача, не раз попадавшаяся в Функциональных дизайнах доработок. Нужно сделать отчёт, оборотную ведомость по месяцам с и по, где даты начала и конца задаёт пользователь. Типа такого:
То есть нужно выбрать данные и сформировать отчёт с заранее неизвестным количеством столбцов. Это решается той самой техникой, которая применена в олимпиадной задаче. Не самая распространённая, но встречающаяся в жизни задача.
Ну и я не разделяю всей этой суеты c практичностью. Задача придумывалась для всесоюзной олимпиады. Нужно было с её помощью отобрать в финал десятку лучших из потенциальных 20 тысяч участников. Тут нельзя давать задачи уровня «свяжите три таблицы, отсортируйте и покажите первые 30 записей». Это все сделают, кроме клинических непрограммистов. Ну и конечно для олимпиадной задачи быть немножко «because we can» никак не повредит.
Точно так же и SQL нам нужен не для выполнения запросов, а для извлечения информации из данных.
Ну вот вам бизнес-задача, не раз попадавшаяся в Функциональных дизайнах доработок. Нужно сделать отчёт, оборотную ведомость по месяцам с и по, где даты начала и конца задаёт пользователь. Типа такого:
месяц1 месяц2 ... месяцN
строка1 ХХХ ХХХ ... ХХХ
строка2 ХХХ ХХХ ... ХХХ
...
То есть нужно выбрать данные и сформировать отчёт с заранее неизвестным количеством столбцов. Это решается той самой техникой, которая применена в олимпиадной задаче. Не самая распространённая, но встречающаяся в жизни задача.
Ну и я не разделяю всей этой суеты c практичностью. Задача придумывалась для всесоюзной олимпиады. Нужно было с её помощью отобрать в финал десятку лучших из потенциальных 20 тысяч участников. Тут нельзя давать задачи уровня «свяжите три таблицы, отсортируйте и покажите первые 30 записей». Это все сделают, кроме клинических непрограммистов. Ну и конечно для олимпиадной задачи быть немножко «because we can» никак не повредит.
Я могу такой пример привести. В детстве, то ли в школе, то ли в деревне у бабушки на каникулах слышал старую поговорку о том, что хороший мастер может построить дом одним топором. То есть если ничего под рукой нет кроме топора, то он все равно не пропадет. Понятно, что когда выбор есть, гвозди он будет забивать молотком, доски пилить пилой и т. д.
Вот тут такая же задача — на виртуозное владение «топором», когда можешь не только дерево срубить, но и целый дом построить.
В общем, хорошая задача.
Вот тут такая же задача — на виртуозное владение «топором», когда можешь не только дерево срубить, но и целый дом построить.
В общем, хорошая задача.
>> Я с таким подходом даже боюсь интересоваться Вашим мнением по поводу школьных задач и упражнений
Вот как раз глубочайшая тема. Мне попадался разбор результатов World pupil rankings in science and maths. Выводы про Россию были весьма плачевными, в некотором роде.
Если требовалось решить задачку из учебника в виде «вот уравнение, решите его», то российские школьники — впереди планеты всей. Но, как только надо задачу из жизни перевести в уравнение и потом это уравнение решить — стопор.
Я в некотором роде увидел это на собственном опыте, когда пытался помочь племяннику с его уроками математике в Германии. (Не помню какой класс) возраст — 11-12 лет. Задачки на простую теорию вероятностей, но условия заданы жизненной ситуацией, а не сразу заданным «решить вот это».
Аналогично, лично для себя — когда я учился в ВУЗе (прикладная математика), то и обратная связь от математики в реальную жизнь была оторвана. Что означает такое решение для реальной жизни? Хоп-ля, неясно.
Аналогично, я на эту же тему разговаривал с коллегой (phd в физике, из Утрехта) — он использовал какие-то российские материалы. Тоже самое — формулировки статей оторваны от жизни.
«Любой дифур можно решить через формулу Коши» и на этом объяснения заканчиваются. Ни как дойти до этого дифура, ни как «прочитать» его решение.
Пару примеров:
Пример из дисера моего папы. Как промежуточный результат, у него было какое-то время в секундах. Ну время и время. Это просто промежуточное значение. Когда он обсуждал это с коллегами, кто-то заметил, что это время сопоставимо со временем существования вселенной. Папахен нашёл ошибку в расчётах
У меня был курсач по теории систем: просчитать наиболее эффективный режим ввода лекарства, оптимизация — стабильность температуры больного. Я получил три результата:
1. Что-то сложное, дозирование
2. Бахнуть сразу всё — температура там через флуктуации придёт к нормальной
3. Вообще не давать лекарства — грубо говоря, дать умереть, температура стабилизируется.
Корректное решение, «в натуре», «в жизни» — только первое.
Вот эти связи — от жизни к формуле, от формылы к жизни как раз и оторваны.
Попросите любого старшеклассника подсчитать:
«Вклад под 3% годовых, вкладываешь 1000р, сколько будет через 10 лет». Всё. Сколько их решит (выведет формулу сначала?) я, в своё время, наблюдал. Единицы. Как сейчас в России — не знаю.
Вот как раз глубочайшая тема. Мне попадался разбор результатов World pupil rankings in science and maths. Выводы про Россию были весьма плачевными, в некотором роде.
Если требовалось решить задачку из учебника в виде «вот уравнение, решите его», то российские школьники — впереди планеты всей. Но, как только надо задачу из жизни перевести в уравнение и потом это уравнение решить — стопор.
Я в некотором роде увидел это на собственном опыте, когда пытался помочь племяннику с его уроками математике в Германии. (Не помню какой класс) возраст — 11-12 лет. Задачки на простую теорию вероятностей, но условия заданы жизненной ситуацией, а не сразу заданным «решить вот это».
Аналогично, лично для себя — когда я учился в ВУЗе (прикладная математика), то и обратная связь от математики в реальную жизнь была оторвана. Что означает такое решение для реальной жизни? Хоп-ля, неясно.
Аналогично, я на эту же тему разговаривал с коллегой (phd в физике, из Утрехта) — он использовал какие-то российские материалы. Тоже самое — формулировки статей оторваны от жизни.
«Любой дифур можно решить через формулу Коши» и на этом объяснения заканчиваются. Ни как дойти до этого дифура, ни как «прочитать» его решение.
Пару примеров:
Пример из дисера моего папы. Как промежуточный результат, у него было какое-то время в секундах. Ну время и время. Это просто промежуточное значение. Когда он обсуждал это с коллегами, кто-то заметил, что это время сопоставимо со временем существования вселенной. Папахен нашёл ошибку в расчётах
У меня был курсач по теории систем: просчитать наиболее эффективный режим ввода лекарства, оптимизация — стабильность температуры больного. Я получил три результата:
1. Что-то сложное, дозирование
2. Бахнуть сразу всё — температура там через флуктуации придёт к нормальной
3. Вообще не давать лекарства — грубо говоря, дать умереть, температура стабилизируется.
Корректное решение, «в натуре», «в жизни» — только первое.
Вот эти связи — от жизни к формуле, от формылы к жизни как раз и оторваны.
Попросите любого старшеклассника подсчитать:
«Вклад под 3% годовых, вкладываешь 1000р, сколько будет через 10 лет». Всё. Сколько их решит (выведет формулу сначала?) я, в своё время, наблюдал. Единицы. Как сейчас в России — не знаю.
НЛО прилетело и опубликовало эту надпись здесь
Я согласен с этим утверждением, мой камент был про более общий вопрос.
Со своей стороны могу сказать, что я не могу сразу «выдать», что мне видится подходящей задачей для олимпиады по сиквелу вообще (так, чтобы и каждый год разные, т.п.)
Со своей стороны могу сказать, что я не могу сразу «выдать», что мне видится подходящей задачей для олимпиады по сиквелу вообще (так, чтобы и каждый год разные, т.п.)
Я со своей стороны думал над этим еще с прошлой статьи про эту олимпиаду и пришел к такой задаче
Существует некий многоэтапный бизнес-процесс.
- Нужно найти нарушителей процесса
- Нужно вычислить производительность всех его участников
- Нужно определить производительность всей системы при новом данном количестве участников
Бизнес-процесс можно выразить графом. Можно сколько угодно менять его структуру, способ его представления в данных и количество участников процесса.
Да какая же это задача. Чему научиться на её примере можно? Это упражнение. Руку набивать. Или её можно дать на собеседовании чтобы посмотреть, как кандидат (а) связывает таблицы, (б) делает групировки и сортировки, (в) как вообще пишет SQL-запросы. Как раз на полчаса-час хватит что пообсуждать, если кандидат сразу не убежит. Теоретически это упражнение должен уметь сделать любой студент, окончивший курс по базам данных, но тут теория с практикой конечно расходятся. А вот сгенерировать динамическую матрицу M на N на SQL сможет очень не кажый даже из тех, кто пишет на SQL на работе за деньги.
Про слизь и панцири в тему, учитывая, что на планете Земля давно победили nosql и orm-фреймворки :)
Не, это только среди ухоженно бородатых, которые смузи с вэйпами потягивают. А промышленные решения ещё годы и десятилетия будут использовать SQL, зачем-то отваливая за софт и сервера такое бабло, о котором авторы orm-фреймворков могут только мечтать…
(тут смайлики по вкусу, а то опять найдутся не понимающий шуток минусаторы)
(тут смайлики по вкусу, а то опять найдутся не понимающий шуток минусаторы)
Я про техническую победу. А это ваше oracle sql за сотни килобаксов нужно лишь чтобы бюджеты осваивать. Что характерно, всем плевать oracle или там hana. Можно ещё туда-сюда помигрировать, чтобы ещё побольше напилить. Это про огого промышленные решения. А стартапы, которые деньги считают давно уже от голого sql ушли. Долго и тормозно.
Годная статья по SQL! Не каждый день месяц встретишь.
А будут у вас еще олимпиады по SQL? Я бы поучаствовал. Задачу про календарь я как-то решал уже, остальные задачи тоже кажутся вполне по силам. Разве что лабиринт вызывает некоторые опасения.
А будут у вас еще олимпиады по SQL? Я бы поучаствовал. Задачу про календарь я как-то решал уже, остальные задачи тоже кажутся вполне по силам. Разве что лабиринт вызывает некоторые опасения.
Поймите меня правильно, я не организатор таких олимпиад. Меня поймали и попросили подготовить техническую часть. Задачи придумал, базу подготовил и провёл мероприятие.
А про олимпиады спрашивайте у гугла, он найдёт кучку. Тот же самый организатор IT-Planet, для которого я готовил задания, делает эти олимпиады ежегодно. Но для студентов и молодых специалистов.
А про олимпиады спрашивайте у гугла, он найдёт кучку. Тот же самый организатор IT-Planet, для которого я готовил задания, делает эти олимпиады ежегодно. Но для студентов и молодых специалистов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Олимпиада SQL: разбор задачи про календарь