Мне кажется, что удобнее задать праздники именно в CTE.
По остальным вопросам все ответы есть в условии: рабочее время с 10:00 до 19:00, что составляет девять часов; предпраздничный день является полным.
А я вот в статье разглядел, что этот самый Т2 умеет менять своё поведение извне. То есть вся новая техника эпла теперь в одном ботнете. Чужим микрофон не даёт, а своим может… И ещё может потенциально что угодно. Прискорбно.
И это только проблема так называемого jitter-а, то есть неустойчивого чтения сигнала. А есть ещё и так называемая проблема синхронизации. В стандарте CD-DA отсутствует информация о начале трека и номер этого трека в самом читаемом блоке. В цифровых CD в 2352 байт на данные остаётся 2048, остальное занято структурами, позволяющими понять, что это и правильно ли прочиталось. А в аудио-CD (которые CD-DA) идёт просто поток байтов в одну дорожку. Как на виниле. Никаких отметок, что у нас начался однатысячакакойтотам сектор нет и в помине. Поэтому драйв, когда его просят прочесть однатысячакакойтотам сектор, тщательно прицеливается и что-то читает. Иногда не одно и то же, если промахивается на несколько байт или несколько десятков-сотен байт…
Развлекался я таким под OS/2 двадцать лет назад. Уже перезабыл почти всё. Но даже на фоне моих давно забытых знаний статья автора (переводчик, надеюсь, не виноват) выглядит забористым бредом. Это уже однако тенденция, когда народ по какой-то левой документации (в данном случае к EAC) пытается понять находядщиеся в свободном доступе стандарты (в данном случае Red Book, в которой описан стандарт cd-da). Софтина конечно была знатная, но кто мешал автору почитать стандарты и не городить кучу необоснованных выводов о том, что прочиталось с диска? Не в первый раз уже встречаю, что народ вместо изучения имеющейся доступной информации начинает гадать на кофейной гуще. Неонеандертальцы какие-то.
Уважаемые 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), которые каждый раз неуловимо могут оказаться в новом месте, для меня тоже являются скорее способом развлечь скучающих бездельников, чем нормальным интерфейсом для профессиональной работы. Разнообразные глюки, вирусы и необходимость время от времени переставлять ОС, потому что она, извините, не умеет за собой подтирать, — это всё заставляет меня избегать этой ОС, когда это возможно.
Почему не может? Никаким условиям не противоречит. Условия говорят, что нужно посчитать, сколько часов из интервала были рабочими.
По остальным вопросам все ответы есть в условии: рабочее время с 10:00 до 19:00, что составляет девять часов; предпраздничный день является полным.
Развлекался я таким под OS/2 двадцать лет назад. Уже перезабыл почти всё. Но даже на фоне моих давно забытых знаний статья автора (переводчик, надеюсь, не виноват) выглядит забористым бредом. Это уже однако тенденция, когда народ по какой-то левой документации (в данном случае к EAC) пытается понять находядщиеся в свободном доступе стандарты (в данном случае Red Book, в которой описан стандарт cd-da). Софтина конечно была знатная, но кто мешал автору почитать стандарты и не городить кучу необоснованных выводов о том, что прочиталось с диска? Не в первый раз уже встречаю, что народ вместо изучения имеющейся доступной информации начинает гадать на кофейной гуще. Неонеандертальцы какие-то.
Эта задача была придумана и использована на втором заочном туре олимпиады по SQL, статью о которой я публиковал раньше. Там как раз объяснялось почему эти пять задач второго тура делались совершенно преднамеренно в стиле, который должен был вызвать у участников вопросы типа «О ужас, да разве такое вообще на SQL делается?!?» Практичность тут не только не была в более низких приоритетах, она вообще не рассматривалась. Если такой подход вызывает вопросы то надо было там это обсуждать, в той статье.
Тут же я дал разбор одной из тех задач. Если есть вопросы по разбору, что-то осталось непонятным, или есть пожелания, что рассмотреть ещё на темы, связанные с SQL, то прошу высказываться. Участвовать в дискуссии о практичности данной задачи, в которую я невольно вступил, я больше не хочу. В контексте того что тут рассматривается только решение, а не создание данной задачи, считаю эту дискуссию неуместной. А то приходят люди со стороны, видят что задача и в самом деле далека от практики, и не разобравшись лепят мне минусы ни за что ни про что, понижая мою мотивацию популяризировать SQL. Предлагаю поставить точку и останоиться. Спасибо.
Если уж речь о практике, то нужной задача становится ровно тогда, когда находится кто-то, готовый заплатить за её решение. Других критериев нужности я пока не встречал. (:
Кстати, в финале мы давали пару задач как раз на технику оптимизации.
Нет, Вы просто не под тем углом на эту задачу смотрите. Это олимпиадная, то есть в первую очередь учебная задача. Работодатель Вам такой задачи никогда не даст.
Ну вот вам бизнес-задача, не раз попадавшаяся в Функциональных дизайнах доработок. Нужно сделать отчёт, оборотную ведомость по месяцам с и по, где даты начала и конца задаёт пользователь. Типа такого:
То есть нужно выбрать данные и сформировать отчёт с заранее неизвестным количеством столбцов. Это решается той самой техникой, которая применена в олимпиадной задаче. Не самая распространённая, но встречающаяся в жизни задача.
Ну и я не разделяю всей этой суеты c практичностью. Задача придумывалась для всесоюзной олимпиады. Нужно было с её помощью отобрать в финал десятку лучших из потенциальных 20 тысяч участников. Тут нельзя давать задачи уровня «свяжите три таблицы, отсортируйте и покажите первые 30 записей». Это все сделают, кроме клинических непрограммистов. Ну и конечно для олимпиадной задачи быть немножко «because we can» никак не повредит.
Конкретно рассмотренная задача берёт из БД год и размер календаря. Пример такой задачи — просмотр каких-нибудь календарных данных (отпусков, отключений горячей воды, дежурств, доступности каких-то ресурсов) в интерфейсе, который может настраиваться по ширине (десктоп и мобильный клиент или самостоятельно пользователем). Если у Вас будет именно такая задача, и лучше всего её будет решать на сервере, то подобного вида запрос как раз и сможет это делать. Хотя для реальной жизни конечно это слишком заумный запрос, поддерживать будет тяжело.
Нормально так можно, если для вышеозначенной обработки текста нужно владеть навыками построения рекурсивных запросов, группировкой и агрегацией данных, да ещё довольно витиевато совместить это всё несколько раз для получения результата. Не говоря уже о том, что декларативный способ решения задач на SQL сам по себе требует мысленных усилий. То есть не каждый владеющий техникой рекурсивных запросов и группировки данных сумеет задачу с генерацией календаря решить.
Для предложенной Вами задачи навыков нужно меньше, а сама задача проще.
А про олимпиады спрашивайте у гугла, он найдёт кучку. Тот же самый организатор IT-Planet, для которого я готовил задания, делает эти олимпиады ежегодно. Но для студентов и молодых специалистов.
(тут смайлики по вкусу, а то опять найдутся не понимающий шуток минусаторы)
А уж о сути реляционных БД я готов с Вами поспорить. Начиная с быстрой обработки (далеко не всегда) сложноструктурированных (зачем же непременно «сложно»?) и до большого объёма. Вот, например, самая распространённая БД на нашей планете — SQLite — отнюдь в большие объёмы не просится, скоростью упирается в железо, на котором работает, сложностью структур обычно тоже не может похвастаться. Но вот удобство работы с данными и хороший запас неубиваемости — и все чайники, микроволновки и пылесосы используют. Ну и смартфоны конечно тоже.
Так вот. А в контексте мака я с Вами не согласен. Интерфейс там вполне соответствует уровню современных ОС. Не так хорош, как у почившей OS/2, но и никак не хуже всем привычной (и почему-то считающейся эталоном) винды. А с учётом хорошей внутренней упаковки всяким софтом прямо из коробки и неплохими возможностями установки дополнительного софта, я считаю макОС как минимум одним из сильнейших кандидатов для домашнего использования. И не только домашнего. Это современный юникс с самым дружественным лицом.
Просьба в меня пингвинами не кидаться, линуксовые дистрибутивы тоже доросли до того уровня, что ими могут пользоватсья домохозяйки, но целостность макОСи на голову выше. Например, все настройки системы делаются в одном месте.
Впрочем, у винды, на мой вкус, проблемы с интерфейсами на всю голову. С появлением этих риббонов IMHO были попраны все человеческие законы и UI, и UX. Когда кнопки для действий стали разной формы, разного размера, то кнопками, то выпадающими списками, то с картинками, то с надписями, да ещё нужно их искать по хаотично и нелогично раскиданным разным закладкам — это, товарищи, полный талибан. Плиточки (tiles), которые каждый раз неуловимо могут оказаться в новом месте, для меня тоже являются скорее способом развлечь скучающих бездельников, чем нормальным интерфейсом для профессиональной работы. Разнообразные глюки, вирусы и необходимость время от времени переставлять ОС, потому что она, извините, не умеет за собой подтирать, — это всё заставляет меня избегать этой ОС, когда это возможно.
Ну и традиционное: самое интуитивное сочетание Alt-F4, которое закрывает окна… (:
(: