LIMIT при запросах с JOIN'ами

[GeT]

LIMIT при запросах с JOIN'ами

Есть вот такой запрос:
[SQL]
SELECT t1.id, t1.title, t2.param_id, t1.price, t2.value
FROM cat_items t1
LEFT JOIN item_properties t2 ON t2.item_id=t1.id
LEFT JOIN properties t3 ON t3.id=t2.param_id WHERE t1.catid=10 ORDER BY t1.pos,t3.pos
[/SQL]

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

Нужно реализовать постраничный вывод, я пытаюсь это сделать с помощью LIMIT'а типа
[SQL]
SELECT t1.id, t1.title, t2.param_id, t1.price, t2.value
FROM cat_items t1
LEFT JOIN item_properties t2 ON t2.item_id=t1.id
LEFT JOIN properties t3 ON t3.id=t2.param_id WHERE t1.catid=10 ORDER BY t1.pos,t3.pos
LIMIT $start,$offset
[/SQL]
Разумеется, ничего дельного данная конструкция не выведет (т.к. кол-во возвращаемых строк чаще всего больше кол-ва "нужных" строк)

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

 

[Necromant]

http://php.com.ua/forum/viewtopic.php?p=22213&highlight=%EF%EE%F1%F2%F0%E0%ED%E8%F7%ED%FB%E9+%E2%FB%E2%EE%E4#22213

 

[GeT]

Necromant
Ты хоть прочитал в чем проблема?

 

[Necromant]

готовый код не нравится
добавь t1.id IS NOT NULL AND t2.id IS NOT NULL

 

[GeT]

Necromant
О, да...
Ты хоть понимаешь что этот запрос делает?
Он для каждого элемента из таблицы1 присоединяет все соответсвующие элементы (подчеркиваю, ИХ НЕСКОЛЬКО МОЖЕТ БЫТЬ) из таблицы 2.
Тоесть для элемента1 может быть 5 строк в результате запроса, может быть 10, минимум - одна.
Твоей гиперфункцией (которая у меня реализована как LIMIT $start, $offset) тут ничего не поделаешь. Надеюсь, понятно почему?

 

[Apache_xp]

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

 

[DimbIch]

Apache_xp
насколько я понял ему просто надо сделать постраничный вывод

 

[Apache_xp]

Думаю, что не совсем, ведь просто лимит его не устраивает!
Пусть задаст нормально, потом отвечу.

 

[GeT]

Apache_xp
Выпей йаду, солнце мое.
Запрос который я написал рабочий, само собой. И если ты считаешь его ерундой, то твои познания в MySQL, видимо, ограничиваются SELECT * FROM table

 

[Apache_xp]

Для особо одаренных:
Я не сказал, что он не рабочий - он просто кривой, вот и все.
Это во - первых, во-вторых перепираться с тобой у меня нет желания = если хочешь получить ответ на вопрос, то уж будь добр хотя бы корректно его формулируй!
Понятно?
P.S. Слово 'яд' пишется через 'Я'

 

[chira]

Apache_xp

Я не сказал, что он не рабочий - он просто кривой, вот и все

насчёт кривости , это громко сказано, пока ничего кривого не видно
GeT

(т.к. кол-во возвращаемых строк чаще всего больше кол-ва "нужных" строк)

ты можешь нас просветить, своими умозаключениями насчёт "нужности" строк?
какие из возврищаемых запросом строк нужные, а какие нет?

 

[alexhemp]

GeT

Ты берешь из таблицы сразу и items и properties.

А листать хочешь только items? Так делай ОТДЕЛЬНЫЙ запрос на список items, а потом для выводимых items читай properties. (список полученных items ты надеюсь можешь получить?).

И с листанием проблем не будет. Не тытайся сделать это одним запросом.

 

[Apache_xp]

chira
По поводу кривости

SELECT t1.id, t1.title, t2.param_id, t1.price, t2.value
FROM cat_items t1
LEFT JOIN item_properties t2 ON t2.item_id = t1.id
>>LEFT JOIN properties t3 ON t3.id = t2.param_id<<
WHERE t1.catid = 10
>>ORDER BY t1.pos, t3.pos<<
Есть такое понятие, как денормализация для таких целей
Это если уж сильно надо по t3.pos упорядочить

 

[chira]

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

 

[Lews]

Автор оригинала: chira
Apache_xp
пока GeT не скажет, какие строки он ожидает от запроса для постраничного вывода, можно делать только предположения ...
GeT
может дашь пример данных в таблицах и что должен выдать SQL?

Представь себе такую ситуацию.. Есть две таблицы, одна из них содержит дома, вторая - квартиры. На каждой странице надо показать 10 домов со всем квартирами. В запросе происходит выборка домов и к каждому дому джойнятся все его квартиры. Т.е., в результате запроса, если, допустим, в каждом доме по 2 квартиры, получается 20 записей. Вопрос сводится к следующему. Как выбрать именно 10 домов со всеми квартирами, не делая отдельно запроса все домов и на каждый дом всех квартир, если такое вобще возможно, так как limit 10,20 даст мне 10 записей, а не 10 домов?

 

[chira]

Lews
это твои догадки насчёт вопроса? возможно они и правильные ...
для реализации твоего представления, самое главное, сделать именно одним запросом?
Для MySQL 4.1 можно сделать одним запросом ...

select d.*,k.*
from (select a.* from dom a limit 10,20) d
,kvartira k
where k.dom_id=d.id

чего GeTа больше не видать, ему наверно уже всё равно ...

 

[GeT]

Сори, у меня иннета день не было.
Lews да, почти то что мне нужно.

chira
К сожалению, у заказчика на сервере MySQL 3.*, твой вариант не проходит.
Я так понял, пока что единственный вариант - сделать чтобы во всех "домах" одного типа было одинаковое число "квартир". И соответственно, до того как делать сам запрос с постраничным выводом делать запрос для нахождения этого "числа".
А потом уже просто $start и $offset умножать на это "число" и писать в запросе.
Других вариантов пока не вижу...

 

[chira]

GeT
Другой вариант использовать временную таблицу.

CREATE TEMPORARY TABLE tt AS
select a.* from dom a limit 10,20;

select d.*,k.*
from tt d
,kvartira k
where k.dom_id=d.id;

 

[GeT]

chira
Данный скрипт - скрипт каталога товаров для веб-магазина.
Ты думаешь разумно использовать запросы с временными таблицами для таких вещей?

 

[MeMO]

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