Доброго времени суток

Делаю выборку из 1 таблицы:

потом обхожу её в цикле и выбираю для каждой записи следующие данные(тут zid это id из первой выборки):


Как эти 2 зарпоса объединить в один?

Заранее благодарен

заменить на pid=mid 

Zloxa, нет, всё работает, просто я хочу 1 запросом вытаскивать все нужные данные, чтобы не нагружать лишний раз сервер, да и не громоздить в коде (просто если первый запрос возвернёт 5000 записей, потом делаю 5000 вторых запросов, что не желательно бы)
т.е. надо получить сразу id, pid, title, sorting, headline, text в ответе

и немного не так вы поняли проблемму... mid это переменная, не имеющая отношения к таблице, можете взять любую константу, например 1
zid(во избежании путаницы, т.к. во втором запросе тоже есть id) это тоже переменная, которая равна id из первого запроса на каждом этапе обхода его курсором например

Это сообщение отредактировал(а) Isaev - 12.11.2013, 12:43

Zloxa, а точно, работает! не думал что так просто, спасибо большое!

Это сообщение отредактировал(а) Isaev - 12.11.2013, 12:54

Пропишите их в селектлисте.


Это вы не правильно поняли, что я вам предложил.
Подумайте еще раз.

Zloxa,  есть только один не приятный момент)
если при "втором" запросе ничего не находится для данного id, то то, что было в первом должно бы оставаться, просто с пустыми полями headline, text
а в данном случае оно, естественно отсеивается
это возможно поправить? думаю там что-то типа JOIN надо использовать

Это сообщение отредактировал(а) Isaev - 12.11.2013, 13:22

Не типа, а именно JOIN. Причём LEFT JOIN. Причём явно указать порядок связывания таблиц - во избежание.

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

Порядок да, не указал я выше нигде... порядок следующий:
`tl_page`основная таблица, откуда берем (id, pid, title, sorting) для результирующей
`tl_article`просто для связи `tl_page` и `tl_content`, там только id и pid
`tl_content` отсюда берём headline, text, если есть соответствие, иначе оставляем эти поля пустыми

Вы тщательнее, тщательнее тужтесь. 

http://segfault.kiev.ua/smart-questions-ru.html#grovelling

Это сообщение отредактировал(а) Zloxa - 12.11.2013, 14:43

Значит, или 
(tl_page INNER JOIN tl_article) LEFT JOIN tl_content
или
(tl_article INNER JOIN tl_page) LEFT JOIN tl_content
А если оптимизатор настолько "умный", что сперва раскроет скобки, а потом про них забудет - то вообще придётся первое связывание выполнять в подзапросе. UPD: фигня, у нас одно левое связывание.

Это сообщение отредактировал(а) Akina - 12.11.2013, 14:50

Если пилить подобие цикла из топикстарта, то page left join (article inner join context)
Но мне кажется усложнение тут излишним. Для начало следовало бы исследовать неприемлимость тупого лефджойна всего прочего к пейджу. Скорее всего он допустим. Разница всплывет лишь в случае неуникальности неконсистентной связи в артиклях.

Это сообщение отредактировал(а) Zloxa - 12.11.2013, 14:58

не, не  я честно убил очередной час
да и для моей задачи и мой вариант годится, там выбока не большая... Просто врождённая слабость к оптимизациям)


её скорее всего тоже нету

т.е. вложенного SELECT тут не будет? почему-то я к нему прихожу постоянно

Это сообщение отредактировал(а) Isaev - 12.11.2013, 15:07

Если в артикле не содержится "подвисших" записей, то вложенный селект не нужен.

Если в артикле пара id,pid ункальна, вложенный селект не нужен.

Если я правильно понял структуру даннных и данные в этой структуре целостны, то оба вышеперечисленных условия должны выполняться. 

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

Добавлено @ 15:19

Именно что убили. Вы не показали ничего, к чему пришли в течении часа. Вы не рассказали что именно у вас не получается и не показали какой дорогой пошли. Это наводит на мысли что вы бы предпочли чтобы вас не направляли в нужную сторону, а тупо сделали бы за вас вашу работу.

А это объясняет - почему у вас отсутствует желание разбиратсья с элементарнейшими основами.  
Если вас не заботит результат, от чего он должен заботить кого-то другого? 

Это сообщение отредактировал(а) Zloxa - 12.11.2013, 15:31

пока возвращает слишком много лишнего

Это сообщение отредактировал(а) Isaev - 12.11.2013, 15:33

Isaev, внимательно... 
Нет, не так. 
ВНИМАТЕЛЬНО перечитайте ещё раз всю тему. Чем ближе к концу, тем внимательнее.

Короче, тему пора закрывать:

либо, если в артикле есть "битые" ссылки на контент, чтобы получить аналог с топикстартом:



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

Это сообщение отредактировал(а) Zloxa - 12.11.2013, 16:19

Тогда уж лучше добавить доп. условие в первый вариант и отсечь зависший контент 

пожалуй, можно еще отфильтровать их добавив в where первого запроса. Наверное как-то так:

Zloxa,   

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

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

Мне кажется ты отфильтровываешь тот кейс, который невер бин хаппенд.


и это. Здесь лучше пид. Если id nullable, а произошел джойн по пиду...

Это сообщение отредактировал(а) Zloxa - 12.11.2013, 17:33

Это опечатка :(


Я фильтрую подвисший текст. Т.е. контент есть, а статьи к нему нет. КАжется...

C учетом того, что контент тут подтягивается через артикль, это не существующий кейс ))

Это сообщение отредактировал(а) Zloxa - 12.11.2013, 21:47

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

Спасибо, ребята! Большое и человеческое