Как получить дополнительные данные из другой таблицы в одном запросе?

Question

[codercat]

Привет

Представим, что есть стена с записями и у каждой записи есть комментарии.
Нужно получить записи и комментарии вместе.

Записи хранятся, например, так:
id owner_id text
---------------------------
1 1 текст_записи1
2 1 текст_записи2
3 1 текст_записи3

Комментарии вот так:
id wall_id owner_id text
------------------------------
1 1 1 комментарий_1
2 2 1 комментарий_2
3 1 1 комментарий_3

На выходе нужно получить массив записей, вроде

[
  {
    "id": 1,
    "owner_id": 1,
    "text": "текст_записи_1",
    "comments": [
    	{
    		"id": 1,
    		"owner_id": 1,
    		"text": "комментарий_1"
    	},
    	{
    		"id": 3,
    		"owner_id": 1,
    		"text": "комментарий_3"
    	},
    ]
  },
  {
    "id": 2,
    "owner_id": 1,
    "text": "текст_записи_2",
    "comments": [
    	{
    		"id": 2,
    		"owner_id": 1,
    		"text": "комментарий_2"
    	}
    ]
  },
  {
    "id": 3,
    "owner_id": 1,
    "text": "текст_записи_3",
    "comments": []
  }
]

Есть какое-то оптимальное и быстрое решение?
Делать два запроса, а потом объединять?

Answer 1

[Владимир Болиев]

Джоины наше все
И еще на вики

Comments

[codercat]

Тут слегка не то, я думаю. Если бы я хотел получить 1 комментарий к записи или подробную информацию о юзере, то я бы использовал join, а тут я не вижу способа применения join'a :/

[Владимир Болиев]

Тут именно то, вам нужен left join

[codercat]

@voff можно попросить у вас написать простенький пример? :/

[codercat]

@voff я с джоинами работал, но именно такую задачу вообще не представляю как решить

[Владимир Болиев]

А вы почитайте ссыки котоорые я вам скинул. И кстати, у вас структура таблиц не верная, у таблицы комментов должна быть связь с таблицей постов.

[codercat]

@voff так есть же связь. У комментариев хранится wall_id (id поста)

[Владимир Болиев]

а, ну обычно пост - это пост, а стена - набор постов, т.е стена -> посты -> комменты. Но тут, конечно, вам виднее. Почитайте про джоины, без понимания основ sql, ничего путного написать не получится.

[Mandor]

Джоины тут использовать не оптимально, т.к. они будут дублировать данные из таблицы с записями (т.е. одна запись будет выдана вам столько раз, со скольки комментариями она сджойнится). Самое простое тут просто делать второй запрос на каждую запись. В дальнейшем можете оптимизировать так, чтобы забирать комментарии сразу для нескольких записей (при помощи wall_id IN ... либо wall_id = 1 or wall_id = 2 ...).

[Владимир Болиев]

@Mandor Со временем, вы обязательно поймете, что самая неоптимальная штука - это запрос в цикле...

[codercat]

@voff так @Mandor и не предлагает делать это в цикле. Предлагает сделать один запрос на получение записей, потом ещё один на получение комментариев, беря id записей

[Mandor]

@voff Я не знаю что будет со временем, я даю совет основываясь на текущем моем опыте. Джоины здесь по нормальному не применить. Есть вариант "для извращенцев": LEFT JOIN + GROUP BY + GROUP_CONCAT(), но лучше дополнительным запросом.

[Владимир Болиев]

@codercat @Mandor Плин, тут стена - это пост, обычная связь один ко многим, никаких извращений. Так и знал что придется все же написать этот запрос: SELECT * FROM walls w LEFT JOIN comments c ON c.wall_id = w.id WHERE w.owner_id = 2

[Mandor]

@voff Я уже писал выше, что при таком банальном джоине получим дублирование информации в записях на стене. Например, 1 запись на стене, у нее 10000 комментариев, при таком джоине получаем 10000 записей на стене. Получение 9999 лишних дубликатов не нужно и не может быть оправдано любовью любыми средствами сделать из двух запросов один.

[Владимир Болиев]

@Mandor Ничего в этом страшного нет, это не дублирование информации, вы немного запутались в терминах. Дублирование тут тоже есть - это owner_id в обоих таблицах, при связи один ко многим. В общем, cтоит закончить дискуссию, если вам интересна тема анализа сложности алгоритмов, почитайте http://habrahabr.ru/post/196560/

[Mandor]

@voff 1. Я не про дублирование информации в разных таблицах, я про дублирование при получении ответа на запрос. 2. В этом вовсе не "нет ничего страшного", в зависимости от содержания БД такой запрос может начать перегонять с сервера БД к приложению да хоть 99% данных, которые будут немедленно удалены (потому что одна строчка будет повторена много раз). 3. То что вы предложили не просто не является оптимальным, а именно противопоказано. Оптимизация, которую вы предложили (а это именно оптимизация - как из двух "железобетонных" запросов к БД сделать один), ну просто ГОРАЗДО хуже простого-тупого способа сделать в лоб двумя запросами. 4. Не понимаю при чем тут сложность алгоритмов. Очевидно что в случае двух запросов она не больше (а скорее всего меньше), чем в случае JOIN запроса. Что-то типа O(n^2) против O(n*2)

[Владимир Болиев]

@Mandor При связи один ко многим, Join будет O(n), как в моем случае, так и в вашем. Серьезно, хватит спорить, просто напишите скриптик, и проверьте при различных входных данных.

[Mandor]

@voff Я не понимаю что я должен проверять. Я не подвергал сомнению результат вашей выборки (тем более результат вы и не написали), а только то, что сам по себе запрос ужасен. O(n) конечно же не будет. В моем случае надо 2 раза (т.к. 2 запроса) произвести по n сравнений (выборка по ключу + не используя индексы, т.к. иначе там бинарные деревья). В вашем случае делается декартово произведение, следовательно x*y сравнений.

Answer 2

[evnuh]

Эх, мало читаете, господа. MySql - реляционная СУБД. Дальше сами должны понять ответ на свой вопрос.

Comments

[Masterme]

И чо?

Answer 3

[Masterme]

> Есть какое-то оптимальное и быстрое решение?
> Делать два запроса, а потом объединять?

Да, делать к СУБД 2 запроса, один для записей, другой для комментариев, а в коде их логически связывать.

Comments

[codercat]

А не могли бы хотя бы пару слов написать о том, почему так лучше, чем join'ами?