null выдаст?

не

в подзапросе либо по всем пользователям собирает disciplines_success, либо по всем дисциплинам с пользователями вместе взятыми.

всего у этого пользователя сдавалось экзаменов 72 раза, по всем специальностям

а, по необходимой специальности - 58 дисциплин, каждая из которых сдавалась, и одна на двойку

остальные по одному разу успешно сданы

а рейтинг максимум 5 (оценка)

В общем, оно там и не будет нормально работать. там группировка в запросе внутри LEFT JOIN. Результаты таких манипуляций не всегда очевидны.
Я пытался поменять иерархию джойнов, и группировки - выдает каждый раз что-то новое и интересное... explain хорошо показывает, что там внутри творится.
Честно, я немного запарился с ним ковыряться, к тому же я не до конца понимаю семантику этих данных.
Вообще, случае, если нужно нестрогое соответствие лефт джойн, и внутри нужно много наворотить можно сделать немного не так. Сделать запрос в виде select ... from tbl1, tbl2, ... where (some1 = some2 or some3 is null) and ...
т.е. явно расписывал в условиях, какую часть какой таблицы оставить несмотря на несовпадения, а не полагался на джойны.
А еще, раз выборка из results_testing явл. основной и результат выборки фигурирует в схеме БД, то лучше изначально от запроса к этой таблице исходить, а джойны запхать в этот запрос, а  не наоборот. Можно вообще сотворить временную таблицу из этой выборки и с ней уже ковыряться
В общем,там нужно въехать что это за данные.

я так толком и не догнал, что это все:
specialtie_to_disciplines
discipline_id
special_id
значит. Не говоря уже об остальных полях. ))

Да и спать что-то хочется, сутки на ногах.
В общем, извини, но меня дальше ломает с ним возиться.

Понимаю, Благодарю за помощь.
result_testing не имею права сделать основным, т.е. основной - это applications, а подзапросом подкармливаю основной запрос, при выборе определённого фильтра пользователем на фронте

Спасибо, Роман. Ты крут )

тогда select ... from applications,, result_testing ... а дальше кувыркаться с джойнами.

я не имею в виду сделать так навсегда. из этого состояния получить, что нужно, а потом завернуть в джойн.

Хм, не слышал

смотри тут вопрос объема данных и какая скорость поиска нужна, так же вопрос нагрузок
поиск через SQL это тяжелый запрос обычно, на больших данных

Тут вопрос с кол-ве динамический параметров, по которым может идти поиск. Если это парочка, то ставишь индекс и никаких проблем нет. Если их 5+, то уже беда

и нужно выносить куда то во внешний no-sql хранилища

Ребят,в чем может быть проблема?

при создании таблицы