Я не работаю в mySQL, но я часто пишу чрезвычайно сложный SQL, и вот как я к нему подхожу.
Во-первых, нет никакой замены для полного понимания структуры вашей базы данных.
Далее я пытаюсь разбить задачу на куски.
Например, предположим, я пишу отчет о деталях встречи (компания, в которой я работаю, занимается планированием встреч). Мне нужно будет знать название встречи и торгового представителя, место и дату встречи, людей, которые сопровождали, и информацию о спикере.
Сначала я определяю, какая из таблиц будет содержать информацию для каждого поля в отчете. Теперь я знаю, что мне придется объединить, но пока не совсем так.
Итак, сначала я пишу запрос, чтобы получить встречи, которые я хочу. Это основа для всего остального отчета, поэтому я начну с него. Теперь остальная часть отчета, вероятно, может быть выполнена в любом порядке, хотя я предпочитаю сначала проработать части, которые должны иметь отношение «один к одному», поэтому затем я добавлю объединения и поля, которые свяжут меня со всеми торговыми представителями. Информация.
Предположим, мне нужно только одно повторение на собрание (если есть несколько повторов, я хочу только основное), поэтому я проверяю, чтобы убедиться, что я все еще возвращаю то же количество записей, что и когда у меня была только информация о собрании. Если нет, я смотрю на свои объединения и решаю, какая из них дает мне больше записей, чем мне нужно. В этом случае это может быть таблица адресов, так как мы храним несколько адресов для представителя. Затем я корректирую запрос, чтобы получить только один. Это может быть легко (у вас может быть поле, которое указывает конкретный уникальный адрес, который вы хотите, и поэтому вам нужно только добавить условие где), или вам может потребоваться выполнить некоторые функции группировки и агрегирования, чтобы получить то, что вы хотите.
Затем я перехожу к следующему фрагменту (работающему сначала через все фрагменты, которые должны иметь отношение 1-1 к центральным данным в данном случае собрания). Выполните запрос и проверяйте данные после каждого добавления.
Наконец, я перехожу к тем записям, которые могут иметь отношение один-много, и добавляю их. Я снова запускаю запрос и проверяю данные. Например, я мог бы проверить необработанные данные для конкретной встречи и убедиться, что мой запрос возвращает именно то, что я ожидаю увидеть.
Предположим, в одном из этих добавлений объединения я обнаружил, что количество отдельных собраний сократилось. К сожалению, в одной из таблиц, которые я только что добавил, нет данных, и мне нужно изменить это на левое соединение.
В другой раз я могу найти слишком много возвращенных записей. Затем я смотрю, нужно ли в моем предложении where иметь больше информации для фильтрации или мне нужно использовать функцию aggreagte для получения нужных мне данных. Иногда я временно добавляю в отчет другие поля, чтобы посмотреть, смогу ли я определить причину дублирования данных. Это помогает мне узнать, что нужно отрегулировать.
Реальный ключ - работать медленно, понимать вашу модель данных и проверять данные после добавления каждого нового чанка, чтобы убедиться, что он возвращает результаты так, как вы думаете.
Иногда, если я возвращаю много данных, я временно помещаю в запрос дополнительное условие where, чтобы ограничить его несколькими элементами, которые я могу легко проверить. Я также настоятельно рекомендую использовать заказ, потому что это поможет вам увидеть, получаете ли вы дублированные записи.