Приглашая опытного разработчика, вы не покупаете, а продаёте

Периодически на почту приходят письма от рекрутеров. Причем в 80% случаев это не прямой работодатель, а кадровое агентство. Предлагают рассмотреть позицию android-разработчика. Описание каждый раз примерно такое:
Работодатель:
Компания, занимающаяся разработкой сервисов (Ни название компании не указано, ни род деятельности)
Требования:
Стандартный скопированный набор java/kotlin, SDK, MV-что-то там
Обязанности:
Разработка android-приложения, взаимодействие с участниками процесса (Ничего себе, кто бы мог подумать? Естественно никакой информации о приложении, участниках и процессах нет)
Условия: Комфортный офис рядом с метро (не указано с каким), белая зп (вилки нет), молодой дружный коллектив

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

Как думать на SQL?

Про WHERE… IN (...) полностью поддерживаю. Скажу за MySQL. До версии 5.6 такие подзапросы в секции WHERE сервер вообще никак не оптимизировал. Позже была добавлена оптимизация простых подзапросов без JOIN'ов.
Так что лучше избегать подобных конструкций и выносить их в секцию с JOIN'ами как, например, показано в комментарии выше.

JavaFX наглядное создание простого приложения и нативная упаковка в Eclipse

Как может кому-то помочь статья о том, как написать программку hello world, которая к тому же еще и не запускается?

Немного о Stream API(Java 8)

Если добавить немного форматирования, то всё становится не так уж плохо:

String campPeople = sport.stream()
                .filter(p -> p.getName() != null)
                .map(SportsCamp::getName)
                .collect(Collectors.joining(" and ",«In camp »," rest all days."));

А вы тоже ищете зависимости в SQL вручную? Тогда мы идем к вам! SQL Dynamite, поиск по объектам базы

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

В Сеть выложили 34-гигапиксельную панораму Праги

Шикарный вид шикарного города.

Неожиданные результаты простого MySQL-запроса

С версии 5.6 мускуль стал оптимизировать конструкции вида WHERE… IN (SELECT ..), но на подзапросы всё равно накладывается ряд ограничений. Подробнее можете почитать в мануале вот тут Optimizing Subqueries with Semi-Join Transformations

Неожиданные результаты простого MySQL-запроса

Вот это вернет вам 5 и 4:

SELECT COUNT(DISTINCT fp2.user_id)
    FROM forum_posts fp2
    WHERE fp2.created >= '2013-01-01'
    AND fp2.created < '2013-02-01'
    GROUP BY DATE(fp2.created)

Неожиданные результаты простого MySQL-запроса

Ну и подзапрос у вас:

...
SELECT fp2.id
    FROM forum_posts fp2
    WHERE fp2.created >= '2013-01-01'
    AND fp2.created < '2013-02-01'
    GROUP BY DATE(fp2.created), fp2.user_id
...

Группируете по DATE(fp2.created), fp2.user_id, а выводите fp2.id. Обычно выводят либо поля, по которым группировка, либо другие, обернутые в агрегатные функции.

Наш вариант теста на знание SQL

К сожалению сейчас даже такие задачи многих соискателей ставят в тупик. 50% кандидатов как правило можно завалить вообще простым заданием на применение обычного LEFT JOIN.

Поведение INSERT… ON DUPLICATE KEY UPDATE в крайней ситуации

А если бы не было в этой таблице автоинкрементного поля, то проблема бы и не возникла. В целом пример показательный.

MySQL. Выбор случайных строк в один запрос

Ага, спасибо, что поправили. Почему-то все время путаю эти термины.

MySQL. Выбор случайных строк в один запрос

На information_schema.tables я бы на вашем месте опираться не стал, т.к., например, для InnoDB столбец TABLE_ROWS содержит лишь грубую оценку количества строк в таблице, а не точное значение.

MySQL. Выбор случайных строк в один запрос

Не забывайте, что функция RAND() — детерминированная, и соответственно в WHERE у вас каждый раз для каждой строки будет вычисляться новое число rand()*100000, так что про индексы тут можете смело забыть.

Оптимизация сложных запросов MySQL

Да, вы правы, я перепутал.

Оптимизация сложных запросов MySQL

> Таким образом если у вас в таблице primary key (ID), key (A,B,C), то в реальности у вас второй ключ не (A,B,C), а (A,B,C,ID).

Тогда уж (ID, A, B, C).

И на мой взгляд как-то многовато воды в статье. Хотелось бы больше примеров на реальных данных и с DDL таблиц.

Как вы чаще всего читаете техническую литературу?

Люблю и по возможности читать бумажные книги, есть в этом какое-то свое удовольствие. Жаль только, что техническая литература всегда довольно объемна и нет возможности постоянно таскать с собой том на 1-2к страниц, так что в дороге в основном пользуюсь планшетом, а в процессе работы ноутбуком.

Ты правда хочешь продолжать заниматься этим, когда тебе исполнится 50 лет?

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

Что нужно делать смолоду или как стать богатым айтишником

И звали его не Вася, а какой-нибудь Пак Чун Ли.

MySQL Query Killer — предохранитель от перегрузки СУБД

Лучше уж сразу потратить время на разработку нормальной системы, чем понаписать непонятно что, а потом править и фиксить все косяки и убивать запросы при этом.

> первичная оптимизация производится в очевидных bottleneck-ах, и последующая — в выявляемых в процессе эксплуатации системы.

Если вы собираетесь выявлять подобные проблемы в процессе эксплуатации, то думаю ваша система долго не протянет.