Ну, это тоже часть правильного использования инструментов при создании запросов и таблиц. )
Странно создавать сущности, которые должны хорошо работать только на тестовых данных. )
Сделать хоть как то — явная провокация. Хороший специалист должен сделать хорошо, а не хоть как то. А если хорошо должен делать другой человек — логично передать ему эту задачу.
Вы комментировали про умение определять сложность алгоритмов, а не умение их писать. ) да и разные бывают алгоритмы, я в других комментариях уже описал)
Ну так мы говорим о том, что считается наградой в жизни.
А упиваться чем то — это получать удовольствие и счастье от чего то, что, на мой вкус, отличная награда.
А какой нужен выхлоп, если награда — в том, что ты получил от этого удовлетворение/счастье?
Классика же — важны не деньги, а впечатления, к примеру.
Соревнуются все — ведь мы боремся за одно и то же: за деньги, статус, признание, обладание очередной модной штучкой и т. д.
На самом деле первая же ложь скрыта вот тут.
Соревнуются не все и должны соревноваться не все.
Просто как то проверить число — да, нужно.
Но это же собеседование, а значит от человека ждут что он покажет какой то крутой алгоритм с хорошей скоростью работы и основанный на красивой математической модели. А это и впрямь скорее задача «алгоритмиста» или СО.
ЗЫ: в подавляющем большинстве случаев.
ЗЫЫ: как мне надоедает, иногда, писать оговорки)
Чаще достаточно знать что хорошо, а что плохо.
Вложенные циклы — плохо.
Поиск по столбцам без индексов — плохо.
И многое-многое другое (ну, учитывая что есть хорошая альтернатива, конечно).
Смысл в том, что знать как использовать важнее чем понимать как работает почти всегда. =)
Сложный вопрос.
Я ответил на голосовалку «Нет, программисту не надо в алгоритмы», из-за постановки в посте.
Всё очень просто — функция нахождения простых чисел и их проверки не простая, имеет много ограничений и простора для оптимизации. Для хорошего решения реально нужен подкованный в математике человек. Для так себе — и впрямь достаточно любого программиста.
Алгори́тм (лат. algorithmi — от арабского имени математика Аль-Хорезми[1]) — конечная совокупность точно заданных правил решения произвольного класса задач или набор инструкций, описывающих порядок действий исполнителя для решения некоторой задачи.
Под это определение подходит всё что делает программист. Даже гуглинг на СО подходит.
А вот решение математических задач хорошей сложности — это совсем другие алгоритмы и они и впрямь нужны очень небольшому числу людей.
Да даже определение сложности «алгоритма» в общем то, не имеет большого смысла чаще всего.
Поэтому — нет, умение самому написать сходу оптимальное решение хорошего уровня математической задачи программистам в подавляющем большинстве не нужно.
А вот строить алгоритмы, которые решают задачи которыми они собираются заниматься они должны и, чаще всего, умеют.
ЗЫ: За 10 лет ни разу не пришлось определять простое число или нет.
Награда определяется количеством людей, на которых вы можете повлиять
В основе нашей игры под названием «жизнь» лежат числа.
Две большие ошибки.
Контрпример прост: саморазвитие. Оно больше всего радости приносит и оно же никак не оценивается цифрами. Но критериями саморазвития могут быть очень разные вещи: размер ЗП, количество людей, на которых ты влияешь, сложность задачи которую решил (и не важно, что сам себе поставил), возможность осознания каких то сложных вещей итп-итп.
Награда — это не деньги и не числа.
Большая часть игр на телефонах совсем этого не требует.
Более того, опять же, вот давать возможность перехвата буфера с паролем от чего то мне совершенно не нужна.
Ну, тут есть несколько нюансов.
1. Не любое. К примеру, игры, всякие треш-приложения итп — зачем им лезть в твой буфер?
2. Люди обычно не видят и не помнят, что у них в буфере лежит.
3. Очень часто буфером пользуются… что бы ввести пароль или логин. Или какие то реквизиты, которые совершенно точно не хочется что бы кто то лишний читал.
Функция ограничения доступа к буферу была бы и впрямь не лишняя.
Я далек от этой темы, но рискну предположить, что не факт «Лучший вариант», возможно для большинства практических случаев это так и есть, но не для всех сценариев. Этот курсорообразный Lag может и хорош, когда записи в последовательности рядом, но если завтра понадобится переделать запрос под далеко отстоящие друг от друга записи, то это значит, что в памяти надо будет держать всю CTE временную таблицу, то есть, кто-то другой будет ждать, пока вы освободите этот десяток-другой гигабайт общей памяти. Плюс, может возникнуть вопрос к актуальности этих данных в памяти.
В случае же вложенного запроса — таки да, есть повторные запросы к таблице. Но цена этих запросов не так уж велика, если поле проиндексировано, — с современными корпоративными SSD. Сколько надо дисковых операций, чтобы выйти, к примеру) на нужную из 2 в степени 40 записей, — всего пару десятков в среднем, типа того. (Тера записей) Не знаю, может вы и правы с этими CTE, но мне это не особенно очевидно для общего случая.
Lag не курсорообразен, а окнообразен. И вполне себе работает так же по индексу — так что тут чистая выгода по сравнению с двойным обращением. =)
С оконными функциями, конечно, свои нюансы (к примеру — забить память до сгружения вычислений на диск), но в таких ситуация и двойной запрос будет печален.
В прочем — в жизни всякое бывает )) и, да — это только про MS SQL. В других системах CTE могут работать принципиально иначе.
Там в оригинале вообще DATEDIFF стоит. Смысл моего комментария был не в том, чтобы найти самое быстрое решение, смысл в том, что вообще кросс джойн там — перебор, можно вполне использовать вложенный запрос. Для этого я и привел код. Я не мог убрать упомянутое вычисление, так как тогда мне сказали бы, что я не корректно сравниваю. Я от DATEDIFF ушел не для оптимизации, а для упрощения кода, — с этими датами в разных системах скорее всего слишком много нюансов.
Очень двоякий вопрос эквивалентности разных решений с одинаковым ответом ))
Но, как кто то выше заметил, нас могут читать джуны, поэтому лишний раз обратить внимание на такие мелочи (совсем не мелкие в плане оптимизации) — не лишне.
ЗЫ: и всё-таки лучше использовать Datediff, потому что, к примеру, тип Date не поддерживает арифметические операции… (
Да и разница между 100р и 150р — совсем не в разы.
Странно создавать сущности, которые должны хорошо работать только на тестовых данных. )
Сделать хоть как то — явная провокация. Хороший специалист должен сделать хорошо, а не хоть как то. А если хорошо должен делать другой человек — логично передать ему эту задачу.
Вы комментировали про умение определять сложность алгоритмов, а не умение их писать. ) да и разные бывают алгоритмы, я в других комментариях уже описал)
А что за реальная цена?)
Ну значит кто то не умеет пользоваться индексами, запросами и планами запросов. )
Отпрашиваются на этот день с работы?
А упиваться чем то — это получать удовольствие и счастье от чего то, что, на мой вкус, отличная награда.
А какой нужен выхлоп, если награда — в том, что ты получил от этого удовлетворение/счастье?
Классика же — важны не деньги, а впечатления, к примеру.
На самом деле первая же ложь скрыта вот тут.
Соревнуются не все и должны соревноваться не все.
Но это же собеседование, а значит от человека ждут что он покажет какой то крутой алгоритм с хорошей скоростью работы и основанный на красивой математической модели. А это и впрямь скорее задача «алгоритмиста» или СО.
ЗЫ: в подавляющем большинстве случаев.
ЗЫЫ: как мне надоедает, иногда, писать оговорки)
Вложенные циклы — плохо.
Поиск по столбцам без индексов — плохо.
И многое-многое другое (ну, учитывая что есть хорошая альтернатива, конечно).
Смысл в том, что знать как использовать важнее чем понимать как работает почти всегда. =)
Я ответил на голосовалку «Нет, программисту не надо в алгоритмы», из-за постановки в посте.
Всё очень просто — функция нахождения простых чисел и их проверки не простая, имеет много ограничений и простора для оптимизации. Для хорошего решения реально нужен подкованный в математике человек. Для так себе — и впрямь достаточно любого программиста.
Под это определение подходит всё что делает программист. Даже гуглинг на СО подходит.
А вот решение математических задач хорошей сложности — это совсем другие алгоритмы и они и впрямь нужны очень небольшому числу людей.
Да даже определение сложности «алгоритма» в общем то, не имеет большого смысла чаще всего.
Поэтому — нет, умение самому написать сходу оптимальное решение хорошего уровня математической задачи программистам в подавляющем большинстве не нужно.
А вот строить алгоритмы, которые решают задачи которыми они собираются заниматься они должны и, чаще всего, умеют.
ЗЫ: За 10 лет ни разу не пришлось определять простое число или нет.
Две большие ошибки.
Контрпример прост: саморазвитие. Оно больше всего радости приносит и оно же никак не оценивается цифрами. Но критериями саморазвития могут быть очень разные вещи: размер ЗП, количество людей, на которых ты влияешь, сложность задачи которую решил (и не важно, что сам себе поставил), возможность осознания каких то сложных вещей итп-итп.
Награда — это не деньги и не числа.
Более того, опять же, вот давать возможность перехвата буфера с паролем от чего то мне совершенно не нужна.
1. Не любое. К примеру, игры, всякие треш-приложения итп — зачем им лезть в твой буфер?
2. Люди обычно не видят и не помнят, что у них в буфере лежит.
3. Очень часто буфером пользуются… что бы ввести пароль или логин. Или какие то реквизиты, которые совершенно точно не хочется что бы кто то лишний читал.
Функция ограничения доступа к буферу была бы и впрямь не лишняя.
Lag не курсорообразен, а окнообразен. И вполне себе работает так же по индексу — так что тут чистая выгода по сравнению с двойным обращением. =)
С оконными функциями, конечно, свои нюансы (к примеру — забить память до сгружения вычислений на диск), но в таких ситуация и двойной запрос будет печален.
В прочем — в жизни всякое бывает )) и, да — это только про MS SQL. В других системах CTE могут работать принципиально иначе.
Очень двоякий вопрос эквивалентности разных решений с одинаковым ответом ))
Но, как кто то выше заметил, нас могут читать джуны, поэтому лишний раз обратить внимание на такие мелочи (совсем не мелкие в плане оптимизации) — не лишне.
ЗЫ: и всё-таки лучше использовать Datediff, потому что, к примеру, тип Date не поддерживает арифметические операции… (