Уважаемые Danik-ik, musicriffstudio, akryukov! Давайте я вам всем вместе отвечу и наконец закрою эту ветку дискуссии, которая относится к практичности данной задачи.
Эта задача была придумана и использована на втором заочном туре олимпиады по SQL, статью о которой я публиковал раньше. Там как раз объяснялось почему эти пять задач второго тура делались совершенно преднамеренно в стиле, который должен был вызвать у участников вопросы типа «О ужас, да разве такое вообще на SQL делается?!?» Практичность тут не только не была в более низких приоритетах, она вообще не рассматривалась. Если такой подход вызывает вопросы то надо было там это обсуждать, в той статье.
Тут же я дал разбор одной из тех задач. Если есть вопросы по разбору, что-то осталось непонятным, или есть пожелания, что рассмотреть ещё на темы, связанные с SQL, то прошу высказываться. Участвовать в дискуссии о практичности данной задачи, в которую я невольно вступил, я больше не хочу. В контексте того что тут рассматривается только решение, а не создание данной задачи, считаю эту дискуссию неуместной. А то приходят люди со стороны, видят что задача и в самом деле далека от практики, и не разобравшись лепят мне минусы ни за что ни про что, понижая мою мотивацию популяризировать SQL. Предлагаю поставить точку и останоиться. Спасибо.
На плохо спроектированной задаче будет уместно ставить задачу на перепроектирование и миграцию без потерь. Это ведь тоже заковыристая задача. Плюс она реальная и нужная.
Если уж речь о практике, то нужной задача становится ровно тогда, когда находится кто-то, готовый заплатить за её решение. Других критериев нужности я пока не встречал. (:
Было бы неплохо видеть подобные на олимпиадах
Кстати, в финале мы давали пару задач как раз на технику оптимизации.
В общем, такие задачи — цель ради достижения, нереально круто и совершенно непрактично. Наверное, я уже подрастерял детско-юношеский максимализм и дошёл до того возраста, когда пафос подобных достижений — ничто...
Нет, Вы просто не под тем углом на эту задачу смотрите. Это олимпиадная, то есть в первую очередь учебная задача. Работодатель Вам такой задачи никогда не даст.
Да не, Вашу мысль я понял ещё за долгие годы до сегодняшних дней. Каких только практических задач мне не попадалось в жизни.
Точно так же и SQL нам нужен не для выполнения запросов, а для извлечения информации из данных.
Ну вот вам бизнес-задача, не раз попадавшаяся в Функциональных дизайнах доработок. Нужно сделать отчёт, оборотную ведомость по месяцам с и по, где даты начала и конца задаёт пользователь. Типа такого:
То есть нужно выбрать данные и сформировать отчёт с заранее неизвестным количеством столбцов. Это решается той самой техникой, которая применена в олимпиадной задаче. Не самая распространённая, но встречающаяся в жизни задача.
Ну и я не разделяю всей этой суеты c практичностью. Задача придумывалась для всесоюзной олимпиады. Нужно было с её помощью отобрать в финал десятку лучших из потенциальных 20 тысяч участников. Тут нельзя давать задачи уровня «свяжите три таблицы, отсортируйте и покажите первые 30 записей». Это все сделают, кроме клинических непрограммистов. Ну и конечно для олимпиадной задачи быть немножко «because we can» никак не повредит.
Знаете, тут нет никакой проблемы. SQL — это ЯП. Несколько специфический, но ЯП. Это инструмент. Если он подходит для решения задачи, то его можно использовать. Если есть более подходящий инструмент, то надо использовать более подходящий. Все вот эти комментарии вокруг, что SQL подходит для этого и не подходит для того, для меня звучат как анекдот про котов. Просто надо уметь готовить. Нам видите ли SQL не для группировки и агрегации (а для чего же ещё?), а C очевидно не для циклов. Рок против наркотиков, коты против сметаны. (голосом Иа-Иа) Ха-ха.
Конкретно рассмотренная задача берёт из БД год и размер календаря. Пример такой задачи — просмотр каких-нибудь календарных данных (отпусков, отключений горячей воды, дежурств, доступности каких-то ресурсов) в интерфейсе, который может настраиваться по ширине (десктоп и мобильный клиент или самостоятельно пользователем). Если у Вас будет именно такая задача, и лучше всего её будет решать на сервере, то подобного вида запрос как раз и сможет это делать. Хотя для реальной жизни конечно это слишком заумный запрос, поддерживать будет тяжело.
как можно проверить степень владения языком запросов по задачам на форматирование текста?
Нормально так можно, если для вышеозначенной обработки текста нужно владеть навыками построения рекурсивных запросов, группировкой и агрегацией данных, да ещё довольно витиевато совместить это всё несколько раз для получения результата. Не говоря уже о том, что декларативный способ решения задач на SQL сам по себе требует мысленных усилий. То есть не каждый владеющий техникой рекурсивных запросов и группировки данных сумеет задачу с генерацией календаря решить.
Для предложенной Вами задачи навыков нужно меньше, а сама задача проще.
Да какая же это задача. Чему научиться на её примере можно? Это упражнение. Руку набивать. Или её можно дать на собеседовании чтобы посмотреть, как кандидат (а) связывает таблицы, (б) делает групировки и сортировки, (в) как вообще пишет SQL-запросы. Как раз на полчаса-час хватит что пообсуждать, если кандидат сразу не убежит. Теоретически это упражнение должен уметь сделать любой студент, окончивший курс по базам данных, но тут теория с практикой конечно расходятся. А вот сгенерировать динамическую матрицу M на N на SQL сможет очень не кажый даже из тех, кто пишет на SQL на работе за деньги.
Поймите меня правильно, я не организатор таких олимпиад. Меня поймали и попросили подготовить техническую часть. Задачи придумал, базу подготовил и провёл мероприятие.
А про олимпиады спрашивайте у гугла, он найдёт кучку. Тот же самый организатор IT-Planet, для которого я готовил задания, делает эти олимпиады ежегодно. Но для студентов и молодых специалистов.
Не, это только среди ухоженно бородатых, которые смузи с вэйпами потягивают. А промышленные решения ещё годы и десятилетия будут использовать SQL, зачем-то отваливая за софт и сервера такое бабло, о котором авторы orm-фреймворков могут только мечтать…
(тут смайлики по вкусу, а то опять найдутся не понимающий шуток минусаторы)
Ой. Это нездоровый практицизм. Я с таким подходом даже боюсь интересоваться Вашим мнением по поводу школьных задач и упражнений. Они к реальной жизни вообще никак не прикладываются. Все экзотерические языки, коих зачем-то понапридумывали десятки, если не сотни, — тоже почему-то не нацелены на практический результат. Ну и так далее, могу привести ещё примеров. Так вот при изучении новой для себя области знаний нужны задачи, которые не важно насколько востребованы. Они нужны, чтобы понять и усвоить новые знания. Осознать, что новый инструмент может, а чего не может. Молоток во время освоения не помешает попробовать и на зуб. А уж для программистов игры чистого разума важны как ни для какой другой специальности, головные ганглии тренировать.
А уж о сути реляционных БД я готов с Вами поспорить. Начиная с быстрой обработки (далеко не всегда) сложноструктурированных (зачем же непременно «сложно»?) и до большого объёма. Вот, например, самая распространённая БД на нашей планете — SQLite — отнюдь в большие объёмы не просится, скоростью упирается в железо, на котором работает, сложностью структур обычно тоже не может похвастаться. Но вот удобство работы с данными и хороший запас неубиваемости — и все чайники, микроволновки и пылесосы используют. Ну и смартфоны конечно тоже.
Не банкир, но минус поставил. Методика может и наивная, но от Вашего комментария толку вообще никакого, один вред. Если Вы против — аргументируйте, а не поливайте грязью.
Знаете, я бы не валил все надкусанные яблоки в одну корзинку. Вот маком мне дома пользоваться удобно и хорошо. Фотки там обработать (кстати, отнюдь не фотошопом, речь о RAW-конвертерах), в интернет слазить, вирусов нет. А в консольке при этом есть и руби с питонами, и весь стандартный юниксовый утиль, и почти весь опенсорц через brew. Красотища. А вот иФонами и иПадами пользоваться мне неудобно, своей цены они для меня не оправдывают. Так что понятия не имею, как с ними бороться. На андроид могу поплакаться, если хотите.
Так вот. А в контексте мака я с Вами не согласен. Интерфейс там вполне соответствует уровню современных ОС. Не так хорош, как у почившей OS/2, но и никак не хуже всем привычной (и почему-то считающейся эталоном) винды. А с учётом хорошей внутренней упаковки всяким софтом прямо из коробки и неплохими возможностями установки дополнительного софта, я считаю макОС как минимум одним из сильнейших кандидатов для домашнего использования. И не только домашнего. Это современный юникс с самым дружественным лицом.
Просьба в меня пингвинами не кидаться, линуксовые дистрибутивы тоже доросли до того уровня, что ими могут пользоватсья домохозяйки, но целостность макОСи на голову выше. Например, все настройки системы делаются в одном месте.
Впрочем, у винды, на мой вкус, проблемы с интерфейсами на всю голову. С появлением этих риббонов IMHO были попраны все человеческие законы и UI, и UX. Когда кнопки для действий стали разной формы, разного размера, то кнопками, то выпадающими списками, то с картинками, то с надписями, да ещё нужно их искать по хаотично и нелогично раскиданным разным закладкам — это, товарищи, полный талибан. Плиточки (tiles), которые каждый раз неуловимо могут оказаться в новом месте, для меня тоже являются скорее способом развлечь скучающих бездельников, чем нормальным интерфейсом для профессиональной работы. Разнообразные глюки, вирусы и необходимость время от времени переставлять ОС, потому что она, извините, не умеет за собой подтирать, — это всё заставляет меня избегать этой ОС, когда это возможно.
Вы неправы с проведённой оценкой. Она вмеру объективна, но полностью бесполезна.
Если Вас полностью устраивает нетбук за 12 тыр (или ещё чего такого), то не факт, что Вы найдёте похожий на него мак. Эппл делает весьма узкую линейку техники, причём скорее топового сегмента. И в своём классе маки весьма неплохи. По некоторым качествам даже уникальны. Например, чтобы не быть голословным, только на маках Вы сможете получить одновременно хорошо упакованный юникс и Фотошоп (и некоторый другой проприетарный софт). Широко известны общественности непревзойдённые тачпады макбуков. Но опять же повторюсь, что линейка их техники довольно узка, на мой взгляд она стала менее интересна, чем при Джобсе, и найти полноценный аналог для любого другого устройства на рынке вряд ли выйдет.
Впрочем, это верно и в обратную сторону: найти полноценный аналог какому-нибудь макбуку про, например, с Touch Bar-ом будет столь же нелегко, как и глупо. Найденный аналог будет отнюдь не дешевле, проиграет сравнение по каким-нибдуь второстепенным признакам, и сольётся полностью при сравнении интеграции ОС с железом (где у Эппла традиционно всё хорошо).
Так что не сравнивайте несравнимое и тогда Ваши действия не будут подвергаться остракизму. (:
Вот-вот. Мне как раз и кажется, что у большей части комментаторов нет перед глазами или в памяти примеров хорошего менеджемента. Отсюда и попытки нафантазировать, что мне бы, мол, как программисту, наверняка было бы легче взаимодействовать с менеджером, который умеет программировать. А вот встретив хорошего менеждера, человек невольно задаётся вопросом, почему же он так хорош и чем именно это определяется. И оказывается внезапно, что отнюдь не знаниями в программировании.
Что-то у меня чешутся руки написать, что если менеджер должен уметь программировать, то наверное и программист должен уметь менеджерить. Как-то набрать и организовать команду, придумать продукт, продать его заказчику, согласовать план работ, получить оплату, свести бюджеты, следить за рисками, замотивировать всех вокруг. Для симметрии вроде как просится…
(Тут должны быть смайлики, а то без них в интернете шутки уже давно не понимают)
Эта задача была придумана и использована на втором заочном туре олимпиады по SQL, статью о которой я публиковал раньше. Там как раз объяснялось почему эти пять задач второго тура делались совершенно преднамеренно в стиле, который должен был вызвать у участников вопросы типа «О ужас, да разве такое вообще на SQL делается?!?» Практичность тут не только не была в более низких приоритетах, она вообще не рассматривалась. Если такой подход вызывает вопросы то надо было там это обсуждать, в той статье.
Тут же я дал разбор одной из тех задач. Если есть вопросы по разбору, что-то осталось непонятным, или есть пожелания, что рассмотреть ещё на темы, связанные с SQL, то прошу высказываться. Участвовать в дискуссии о практичности данной задачи, в которую я невольно вступил, я больше не хочу. В контексте того что тут рассматривается только решение, а не создание данной задачи, считаю эту дискуссию неуместной. А то приходят люди со стороны, видят что задача и в самом деле далека от практики, и не разобравшись лепят мне минусы ни за что ни про что, понижая мою мотивацию популяризировать SQL. Предлагаю поставить точку и останоиться. Спасибо.
Если уж речь о практике, то нужной задача становится ровно тогда, когда находится кто-то, готовый заплатить за её решение. Других критериев нужности я пока не встречал. (:
Кстати, в финале мы давали пару задач как раз на технику оптимизации.
Нет, Вы просто не под тем углом на эту задачу смотрите. Это олимпиадная, то есть в первую очередь учебная задача. Работодатель Вам такой задачи никогда не даст.
Ну вот вам бизнес-задача, не раз попадавшаяся в Функциональных дизайнах доработок. Нужно сделать отчёт, оборотную ведомость по месяцам с и по, где даты начала и конца задаёт пользователь. Типа такого:
То есть нужно выбрать данные и сформировать отчёт с заранее неизвестным количеством столбцов. Это решается той самой техникой, которая применена в олимпиадной задаче. Не самая распространённая, но встречающаяся в жизни задача.
Ну и я не разделяю всей этой суеты c практичностью. Задача придумывалась для всесоюзной олимпиады. Нужно было с её помощью отобрать в финал десятку лучших из потенциальных 20 тысяч участников. Тут нельзя давать задачи уровня «свяжите три таблицы, отсортируйте и покажите первые 30 записей». Это все сделают, кроме клинических непрограммистов. Ну и конечно для олимпиадной задачи быть немножко «because we can» никак не повредит.
Конкретно рассмотренная задача берёт из БД год и размер календаря. Пример такой задачи — просмотр каких-нибудь календарных данных (отпусков, отключений горячей воды, дежурств, доступности каких-то ресурсов) в интерфейсе, который может настраиваться по ширине (десктоп и мобильный клиент или самостоятельно пользователем). Если у Вас будет именно такая задача, и лучше всего её будет решать на сервере, то подобного вида запрос как раз и сможет это делать. Хотя для реальной жизни конечно это слишком заумный запрос, поддерживать будет тяжело.
Нормально так можно, если для вышеозначенной обработки текста нужно владеть навыками построения рекурсивных запросов, группировкой и агрегацией данных, да ещё довольно витиевато совместить это всё несколько раз для получения результата. Не говоря уже о том, что декларативный способ решения задач на SQL сам по себе требует мысленных усилий. То есть не каждый владеющий техникой рекурсивных запросов и группировки данных сумеет задачу с генерацией календаря решить.
Для предложенной Вами задачи навыков нужно меньше, а сама задача проще.
А про олимпиады спрашивайте у гугла, он найдёт кучку. Тот же самый организатор IT-Planet, для которого я готовил задания, делает эти олимпиады ежегодно. Но для студентов и молодых специалистов.
(тут смайлики по вкусу, а то опять найдутся не понимающий шуток минусаторы)
А уж о сути реляционных БД я готов с Вами поспорить. Начиная с быстрой обработки (далеко не всегда) сложноструктурированных (зачем же непременно «сложно»?) и до большого объёма. Вот, например, самая распространённая БД на нашей планете — SQLite — отнюдь в большие объёмы не просится, скоростью упирается в железо, на котором работает, сложностью структур обычно тоже не может похвастаться. Но вот удобство работы с данными и хороший запас неубиваемости — и все чайники, микроволновки и пылесосы используют. Ну и смартфоны конечно тоже.
Так вот. А в контексте мака я с Вами не согласен. Интерфейс там вполне соответствует уровню современных ОС. Не так хорош, как у почившей OS/2, но и никак не хуже всем привычной (и почему-то считающейся эталоном) винды. А с учётом хорошей внутренней упаковки всяким софтом прямо из коробки и неплохими возможностями установки дополнительного софта, я считаю макОС как минимум одним из сильнейших кандидатов для домашнего использования. И не только домашнего. Это современный юникс с самым дружественным лицом.
Просьба в меня пингвинами не кидаться, линуксовые дистрибутивы тоже доросли до того уровня, что ими могут пользоватсья домохозяйки, но целостность макОСи на голову выше. Например, все настройки системы делаются в одном месте.
Впрочем, у винды, на мой вкус, проблемы с интерфейсами на всю голову. С появлением этих риббонов IMHO были попраны все человеческие законы и UI, и UX. Когда кнопки для действий стали разной формы, разного размера, то кнопками, то выпадающими списками, то с картинками, то с надписями, да ещё нужно их искать по хаотично и нелогично раскиданным разным закладкам — это, товарищи, полный талибан. Плиточки (tiles), которые каждый раз неуловимо могут оказаться в новом месте, для меня тоже являются скорее способом развлечь скучающих бездельников, чем нормальным интерфейсом для профессиональной работы. Разнообразные глюки, вирусы и необходимость время от времени переставлять ОС, потому что она, извините, не умеет за собой подтирать, — это всё заставляет меня избегать этой ОС, когда это возможно.
Ну и традиционное: самое интуитивное сочетание Alt-F4, которое закрывает окна… (:
(:
Если Вас полностью устраивает нетбук за 12 тыр (или ещё чего такого), то не факт, что Вы найдёте похожий на него мак. Эппл делает весьма узкую линейку техники, причём скорее топового сегмента. И в своём классе маки весьма неплохи. По некоторым качествам даже уникальны. Например, чтобы не быть голословным, только на маках Вы сможете получить одновременно хорошо упакованный юникс и Фотошоп (и некоторый другой проприетарный софт). Широко известны общественности непревзойдённые тачпады макбуков. Но опять же повторюсь, что линейка их техники довольно узка, на мой взгляд она стала менее интересна, чем при Джобсе, и найти полноценный аналог для любого другого устройства на рынке вряд ли выйдет.
Впрочем, это верно и в обратную сторону: найти полноценный аналог какому-нибудь макбуку про, например, с Touch Bar-ом будет столь же нелегко, как и глупо. Найденный аналог будет отнюдь не дешевле, проиграет сравнение по каким-нибдуь второстепенным признакам, и сольётся полностью при сравнении интеграции ОС с железом (где у Эппла традиционно всё хорошо).
Так что не сравнивайте несравнимое и тогда Ваши действия не будут подвергаться остракизму. (:
(Тут должны быть смайлики, а то без них в интернете шутки уже давно не понимают)
Значит мой совет был не для Вас, и его можно было просто проигнорировать.
Искренне рад, что Вы нашли полностью устраивающий Вас путь своего развития. Держите нас в курсе (: