подзапросов без где-п

Question

Вот мой код

SELECT res.type, 
     res.contactname, 
     res.id, 
     res.inv_addressline2, 
     res.inv_addressline3, 
     res.signup_date, 
     res.engineer_id_global, 
     res.job_id_global, 
     res.neg_or_pos, 
     res.rating, 
     res.author_id_global, 
     res.timestamp_global, 
     res.short_description, 
     res.job_title, 
     res.feedback, 
     author_data.contactname AS `author_name`, 
     review_count.total_feedback, 
     review_count.total_rating 
FROM (SELECT mb.type, 
      mb.contactname, 
      mb.id, 
      mb.inv_addressline2, 
      mb.inv_addressline3, 
      mb.signup_date, 
      fb.engineer_id AS `engineer_id_global`, 
      fb.timestamp AS `timestamp_global`, 
      fb.job_id AS `job_id_global`, 
      fb.neg_or_pos, 
      fb.rating, 
      fb.feedback, 
      fb.author_id AS `author_id_global`, 
      ac.engineer_id, 
      ac.timestamp, 
      ac.author_id, 
      jb.job_id, 
      SUBSTR(jb.job_description, 1, 200) AS `short_description`, 
      jb.job_title 
     FROM " . MEMBERS_TABLE . " AS mb 
     LEFT JOIN " . ACCEPTED . " AS ac 
      ON mb.id = ac.engineer_id 
     LEFT JOIN " . FEEDBACK . " AS fb 
      ON ac.job_id = fb.job_id 
     LEFT JOIN " . JOBS . " AS jb 
      ON fb.job_id = jb.job_id 
     WHERE mb.type = 2 
     ORDER BY 
      fb.timestamp DESC 
    ) AS res 
LEFT JOIN 
    (SELECT mb.id, 
      mb.contactname, 
      fb.author_id 
    FROM " . MEMBERS_TABLE . " AS mb 
    LEFT JOIN " . FEEDBACK . " AS fb 
      ON fb.author_id = mb.id 
    LIMIT 1 
    ) AS `author_data` 
     ON res.author_id_global = author_data.author_id 
LEFT JOIN 
    (SELECT COUNT(fb.engineer_id) AS `total_feedback`, 
      SUM(fb.rating) AS `total_rating`, 
      fb.engineer_id 
    FROM " . FEEDBACK . " AS fb 
    ) AS `review_count` 
     ON res.engineer_id_global = review_count.engineer_id 
GROUP BY res.contactname 
ORDER BY res.contactname 

Я только начинаю, чтобы получить мою голову вокруг SQL. Мое беспокойство - это второй и третий внутренний запрос. Правильно ли я говорю, что он вернет все результаты, так как нет предложения where и возвращаются результаты от использования с помощью оператора «ON» или «ON» в сочетании с исходным запросом?

Answer 1

Есть целый ряд вопросов, с этим скриптом:

• У вас есть несколько таблиц с именами, как " . MEMBERS_TABLE . ", " . ACCEPTED . " и так далее. Они вряд ли будут приемлемыми в MySQL, которые обычно используют backticks (`) для цитирования имен объектов; если этот скрипт должен быть предварительно обработан, например. Perl или Python, или является частью большого скрипта на другом языке, было бы полезно сказать об этом.
• У вас есть order by пункт, без видимых причин, в вашем первом подзапросе. Это можно удалить.
• Ваши второстепенные ссылки ссылаются на FEEDBACK на MEMBERS_TABLE и ограничивают результаты до 1, не указывая author_id внутри подзапроса - это означает, что во вспомогательном запросе будет выбран один случайный элемент, а затем привязан к остальная часть набора данных на конкретном идентификаторе автора, который не будет соответствовать большей части остальной части набора данных.
  • Таблица FEEDBACK здесь совершенно не имеет отношения к делу и может быть удалена.
  • Если id уникально идентифицирует запись на MEMBERS_TABLE, суб-запрос может быть полностью удален и заменен одним левым соединением в MEMBERS_TABLE на res.author_id_global = MEMBERS_TABLE.id. Предложение № limit потребуется.
  • Если id не однозначно идентифицирует запись в MEMBERS_TABLE, суб-запрос должен быть переписан как select distinct id, contact_name FROM " . MEMBERS_TABLE . " AS mb where res.author_id_global = mb.id LIMIT 1. Если для одного и того же id есть несколько авторов, их можно было бы выбрать произвольно.
• Третий суб-запрос не требует пункт where - это суммировать отзывы и рейтинги всех инженеров инженером в суб-запроса, и каждый инженер затем будет связан с соответствующим инженером от остальной части набор данных по состоянию on из пункта left join.

Answer 2

Второй внутренний запрос имеет ограничение 1. Это ничего, кроме условия, чтобы показать только один результат. Третий внутренний запрос не имеет проблем.