[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Сложный запрос
Bezdna
Решил на ночь глядя заняться одной старой проблемой и понял, что то ли лыжи не едут, то ли давно я ничем подобным не занимался. В связи с чем прошу уважаемое сообщество дать пинка в нужном направлении.

Суть: есть запрос из множества таблиц (не знаю насколько правильный, но работает).
 
SELECT o.`object`, o.`oid`, b.`bobject`, b.`boid`, e.*, z.`readiness`, z.`or_ins`, t.*
FROM `objects` AS o
LEFT JOIN `big_objects` AS b ON b.`boid` = o.`unid`
JOIN `equipment` AS e
LEFT JOIN `obor` AS t ON t.`cid` = e.`agregat`
LEFT JOIN `order` AS z ON e.`qid` = z.`or_obor_id`
AND z.`readiness` = '1'
WHERE `a_unid` = e.`qid` AND e.`qobj` = o.`oid`
ORDER BY b.`bobject`, o.`object` ASC


Существует ещё таблица 'attach', в которой, как, в общем-то, понятно из названия, хранятся данные на прикреплённые файлы. Этих файлов, соответственно, может быть любое количество.
Собственно вопрос: как можно выбрать количество этих прикреплённых файлов, при условии что основной идентификатор e.`qid`?
chee
Если я правильно понял, то

SELECT o.`object`, o.`oid`, b.`bobject`, b.`boid`, e.*, z.`readiness`, z.`or_ins`, t.*, (SELECT COUNT(*) FROM attach WHERE parent_id = e.qid) AS attach_count
FROM `objects` AS o
LEFT JOIN `big_objects` AS b ON b.`boid` = o.`unid`
JOIN `equipment` AS e
LEFT JOIN `obor` AS t ON t.`cid` = e.`agregat`
LEFT JOIN `order` AS z ON e.`qid` = z.`or_obor_id`
AND z.`readiness` = '1'
WHERE `a_unid` = e.`qid` AND e.`qobj` = o.`oid`
ORDER BY b.`bobject`, o.`object` ASC


_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Bezdna
Похоже что лыжи всё-таки едут - эту часть (SELECT COUNT(*) FROM attach WHERE parent_id = e.qid) я зачем-то пытался приджойнить во второй части запроса.

В общем - всё заработало. Спасибо.
Ron
Как должен работать этот запрос? На каждую строку выполняться еще один SELECT?
Bezdna
Ron , не понял сути вопроса. Если что-то не так, то можно поподробнее?
Ron
Bezdna, нет, я не с критикой. Просто интересно как должен выполняться этот запрос. Там вложенный селект зависит от приджойненной таблицы. Неужели на каждую строку будет выполняться еще один (этот вложенный) select?


chee
Ron, возможно, но даже если и так, то какая разница если этот подход не требует много ресурсов.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Bezdna
Цитата (Ron @ 11.06.2016 - 19:52)
я не с критикой


Да и я не с претензиями biggrin.gif . Этот запрос я "сочинил" 4 года назад, с тех пор программированием практически не занимался. Поэтому уже и сам плохо понимаю что там будет выполняться и как. Просто сейчас возникла необходимость это моё "творение" немного модернизировать. Поэтому я и попросил помощи. И если есть возможность ещё что-либо посоветовать, то буду весьма признателен.
Bezdna
Цитата (chee @ 11.06.2016 - 22:16)
если этот подход не требует много ресурсов


Насчёт ресурсов тоже сказать сложно, но при условии что на страницу выводит таблицу с 30 строками информации, пишет что "Время выполнения: 0.44 с || Расход памяти: 118,464 байт". Насколько это ресурсоёмко судить вам.
Kusss
Bezdna
время SQL запроса , или php ? Если SQL - то это долго.
Bezdna
Kusss, это время полной загрузки страницы, т.е. получается - всё скопом. Если учесть, что это сайт со служебной информацией, на который заходит максимум 5 человек в день, думаю ничего особо смертельного в этих цифрах нет. Или я не прав?


Kusss
Ну если записей мало - то пофигу. А вот если их наберется несколько десятков тысяч - стоит оптимизировать.
Ты проверь сколько выполняется чистый запрос. И посмотри EXPLAIN запроса, сколько строк перебирается.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.