Лучший подход для построения сложных объединений MySQL и групп?

Я не работаю в mySQL, но я часто пишу чрезвычайно сложный SQL, и вот как я к нему подхожу.

Во-первых, нет никакой замены для полного понимания структуры вашей базы данных.

Затем я пытаюсь разбить задачу на куски.

Например, предположим, что я пишу отчет о деталях встречи (компания, для которой я работаю, занимается планированием встреч). Мне нужно знать имя собрания и представителя по продажам, место встречи и даты встречи, людей, которые прислушиваются, и информацию о спикерах.

Сначала я определяю, какая из таблиц будет содержать информацию для каждого поля в отчете. Теперь я знаю, что мне нужно будет объединить, но не совсем так, как пока.

Итак, сначала я пишу запрос, чтобы получить нужные мне собрания. Это является основой для всего остального отчета, поэтому я начинаю там. Теперь остальная часть отчета, вероятно, может быть выполнена в любом порядке, хотя я предпочитаю работать через части, которые должны иметь односторонние отношения, сначала, поэтому я добавлю объединения и поля, которые получат мне всю связанную с продажей репутацию Информация.

Предположим, что мне нужен только один повтор на встречу (если есть несколько повторений, я хочу только основной), поэтому я проверяю, чтобы я все еще возвращал такое же количество записей, как когда у меня была только информация о собрании. Если нет, я смотрю на свои объединения и решаю, какой из них дает мне больше записей, чем мне нужно. В этом случае это может быть таблица адресов, поскольку мы храним несколько адресов для rep. Затем я корректирую запрос, чтобы получить только один. Это может быть легко (у вас может быть поле, указывающее конкретный уникальный адрес, и вам нужно только добавить условие), или вам может понадобиться выполнить некоторые функции группировки и агрегации, чтобы получить то, что вы хотите.

Затем я перехожу к следующему фрагменту (сначала работаю через все куски, которые должны иметь отношение 1-1 к центральным данным в этом случае, встреча). Runthe query nd проверяет данные после каждого добавления.

Наконец, я перехожу к тем записям, которые могут иметь отношения "один-много" и добавлять их. Снова я запускаю запрос и проверяю данные. Например, я могу проверить необработанные данные для конкретной встречи и убедиться, что мой запрос возвращается, именно то, что я ожидаю увидеть.

Предположим, что в одном из этих дополнений к соединению я обнаружил, что количество отдельных совещаний сократилось. К сожалению, в одной из таблиц, которые я только что добавил, нет данных, и мне нужно изменить их на левое соединение.

В другой раз я могу найти слишком много записей. Затем я смотрю, нужно ли иметь предложение my where для получения дополнительной информации о фильтрации или если мне нужно использовать функцию aggreagte для получения необходимых мне данных. Иногда я иногда добавляю другие поля в отчет, чтобы увидеть, могу ли я увидеть, что вызывает дублированные данные. Это помогает мне понять, что нужно отрегулировать.

Настоящий ключ - медленно работать, понимать вашу модель данных и проверять данные после добавления каждого нового куска, чтобы убедиться, что он возвращает результаты так, как вы думаете.

Иногда, если я возвращаю много данных, я временно добавлю предложение additonal where в запрос, чтобы ограничить несколько элементов, которые я могу легко проверить. Я также настоятельно рекомендую использовать порядок, потому что это поможет вам понять, получаете ли вы дублированные записи.