MySql несколько строк в одном ряде.

[Earlot]

MySql несколько строк в одном ряде.

нужно одним запросом сформировать структуру, соединяющую 2 таблицы.

связь таблиц:
по ключевому полю первой таблицы во второй таблице соответствует несколько строк
(один ко многим)

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

это легко сделать в цикле, но на него нет времени. нужно, чтобы работало максимально быстро. большие объемы..

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

я думаю, должно быть простое решение на самой базе

наверное, это очень просто - но я не нашел по поиску.
в мануале тоже

 

[Фанат]

но такой подход тоже нагружает сервер.

переживёт твоё сервер такую неимоверную нагрузку.

я думаю, должно быть простое решение на самой базе

а я не думаю.

большие объемы..

какие ещё "большие объёмы"?
в вебе по определению больших объёмов не бывает.
моддем юзера сдохнет гораздо раньше, чем сервер заметит хоть какую-то нагрузку.

 

[netmac]

Не, ну вот а как ты представляешь результат этой чудо функции???

Та связь которую ты хочешь сделать противоречит вообще основным концепциям реляционных баз данных.

Самый простой, быстрый и правильный вариант делать два отдельных запроса.

один запрос кончается там, где начинается связь один ко многим.

 

[Romashov]

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

 

[white phoenix]

Оптимизация имеет смысл только тогда когда она имеет смысл.

 

[Earlot]

смысл определенно имеет. два запроса - думаю все-таки подойдет.. протестирую скорость работы обоих решений.

в данном случае оптимизация имеет смысл, т.к. реально в таблицах много полей и значений, на страницу выводится порядка 8000 строк и рассчитана система никак не на модемы.
при увеличении пользователей до 70 одновременно сервер начинает тормозить.

 

[SiMM]

Интересно, накой нужны пользователю эти 8000 строк (таблицы?) за раз? Вот не верю я, что он все их будет внимательно и вдумчиво читать.

 

[Earlot]

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

 

[Romashov]

хочет вдумчивого чтения - пусть подождёт, скрипты тоже не могут мгновенно думать

 

[netmac]

Оптимизация имеет смысл всегда, когда она приносит положительный результат, ценность которого сопоставима с затратами на эту оптимизацию.

В данном случае попытка все запихнуть в один запрос абсолютно ни к чему. И не важен размер таблицы и кто там что будет читать.
1. Искуственно нарашивается объем обрабатываемых данных на сервере БД, что скорости не прибавит.
2. Как данные будут выводится в PHP? Один Многомерный массив? Массивы особенно большие и многомерные - слабая сторона PHP. Это все занают. Опять потеряешь в скорости.

Где тут оптимизация?

И не правильно это. Почитай что-нибудь фундаментальное по реляционным БД. А то многие говорят реляционная, а что это значит не знают.

 

[Earlot]

netmac читаю как раз сейчас
спасибо.
да.. не получается скорее..
интересно то, что если делать запрос даже на каждой строке в базу - скорость конечно падает, но не сильно.