Упрощу структуру, чтобы не путаться в специфике базы:
Есть таблица master m и detail d.
Нужно вывести запрос строк из master + значение, говорящее о том, что для master СУЩЕСТВУЮТ значения в detail-таблице, и при этом дата окончания ни в одном из них непустая.
Сейчас запрос выглядит следующим образом:
авторSELECT m.*, (IF ((d_ex.id IS NOT NULL) AND (d_nul.id IS NULL), 'Y', 'N')) AS all_finished // lдетайлы существуют и нет незавершенных
FROM master m
LEFT JOIN detail d_ex ON d_ex.master_id = m.id // существование детайлов
LEFT JOIN detail d_nul ON (d_nul.master_id = m.id) AND ((d_nul.finish_time = '1899-12-30') OR (d_nul.finish_time IS NULL)) // присутствие незавершенных среди существующих

Однако выполняется он очень долго - 14 секунд.
Как только закомментируешь хотя бы один из этих джойнов, скорость возрастает до 2 секунд.
Но как тогда вместить все в один джойн, если это противоположные требования? В первом надо определить существование, а во втором - несуществование.

Упрощу структуру, чтобы не путаться в специфике базы:
Есть таблица master m и detail d.
Нужно вывести запрос строк из master + значение, говорящее о том, что для master СУЩЕСТВУЮТ значения в detail-таблице, и при этом дата окончания ни в одном из них непустая.
Сейчас запрос выглядит следующим образом:




Однако выполняется он очень долго - 14 секунд.
Как только закомментируешь хотя бы один из этих джойнов, скорость возрастает до 2 секунд.
Но как тогда вместить все в один джойн, если это противоположные требования? В первом надо определить существование, а во втором - несуществование.

AkinaА, да... GROUP BY m.id либо просто DISTINCT добавь. А то для тех записей, для которых есть соответствия более одного, вылезут дубли.
Да, там есть, я просто забыл здесь написать.

AkinaОдно плохо - значения-признаки будут дублироваться в каждой записи... некошерно... почему не получить их вторым запросом?
Это сообщение не понял.

AkinasvnvladЕсть таблица master m и detail d.
Нужно вывести запрос строк из master + значение, говорящее о том, что для master СУЩЕСТВУЮТ значения в detail-таблице, и при этом дата окончания ни в одном из них непустая.



Если первое верно MAX(d.master_id) IS NULL DetailsNotExist,
то второе MAX(d.finish_time) > '1899-12-30' NullsNotExist не дает правильного результата.

EMS MySQL Manager странно работает. Вношу с его помощью в дату значение '1899-30-12 00:00:00', он превращает его в 0000-00-00 00:00:00', соответственно, запрос его не находит как WHERE finish_time = '1899-12-30', однако, находит как WHERE finish_time = 0.
С другой стороны, в базе реально есть значения "1899-12-30 00:00:00", и их он находит как WHERE finish_time = '1899-12-30'.
Получается на нулевое значение даты надо проверять по 3-м признакам?
1. NULL
2. 1899-12-30
3. 0

Akina,
а вот так тоже нормально?

Akina,

тип DATETIME.

Немного усложним задачу. На самом деле в таблице detail не одна ссылка master_id, а две.
from_master_id и to_master_id. Заполняется только одна из них, либо from_master_id, либо to_master_id.
Соответственно, другая будет Null.
И тут у меня возникают трудности, как данный запрос адаптировать к этой системе.

Вроде бы решил

Akinasvnvladтип DATETIME.
https://dev.mysql.com/doc/refman/5.7/en/datetime.html The DATETIME type is used for values that contain both date and time parts. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.
Так что '1899-30-12 00:00:00' - вполне себе легитимное значение для этого типа поля. А наблюдаемая проблема - хороший повод деинсталлировать глючный софт и перейти на нечто более вменяемое.

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

svnvladНа самом деле в таблице detail не одна ссылка master_id, а две.
from_master_id и to_master_id. Заполняется только одна из них, либо from_master_id, либо to_master_id.
Соответственно, другая будет Null.Ну привязывай две копии и используй COALESCE для выбора Not-NULL значения из двух. Делов-то... впрочем, что бы с учётом этого бреда не подумать об изменении структурки?
Там выше, уже решил.
По поводу структуры, тут master - это карточка груза (включает местоположение), а detail - это операции перегрузки, в ней отражается с какой карточки в какую груз был перегружен. Поэтому, собственно, сама карточка остается master-ом, а в detaile две ссылки - на карточку "откуда", и на карточку "куда".

Akinasvnvladdetail - это операции перегрузки, в ней отражается с какой карточки в какую груз был перегружен.Избыточно и потенциально противоречиво. Достаточно информации, куда. А откуда - определяется уже имеющимися данными.
А как отобразить такой процесс?
Приехало 10 автомобилей с грузом. Каждая партия этого груза - это отдельная карточка. В данном случае на одном автомобиле одна карточка груза. Включает в себя номер договора, вес, условия перевозки, ссылка на автомобиль.
Эти 10 авто разгружают на склад №1 в одну кучу, формируя таким образом новую карточку - карточку груза склада. Она включает номер договора, вес (в ней уже суммированные веса всех 10 партий), № склада.
В существующей схеме в таблице transshipment имеется ссылка from_cargo_card_id и to_cargo_card_id. Соответственно в ней сформируется 10 строк, отражающих историю всех перегрузок, их продолжительность, ответственного и т.д.

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

И еще теоретически могут карточку одного автомобиля разгрузить частично на один склад, частично на другой, т.е. в 2 разных карточки.