|
|
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Положим есть 2 таблицы: City Код: plaintext 1. 2. 3. 4. Person Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: plsql 1. Вот что прописать в OFFSET и LIMIT не понятно. Есть идеи как все это замутить с использованием вложенного SELECT, но коряво это. Наверняка есть более элегантное решение? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 00:00 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaillВот что прописать в OFFSET и LIMIT не понятно.тут должен быть вопрос не что прописать, а куда... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 00:20 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
ок, куда? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 00:34 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaillок, куда? )в тот самый "вложенный SELECT". Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 01:53 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
p2., Спасибо, это работает, но я изначально слишком сократил постановку задачи для простоты. На самом деле: Мне необходимо написать запрос который бы возвращал, скажем, два города с людьми в них проживающих имена которых содержат букву "a" . Т.е. если в городе Х нет людей с буквой "a", то возвращать город не надо. Поверх этого, как я ранее говорил, нужно пагинация. Как-то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 09:15 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaillp2., Спасибо, это работает, но я изначально слишком сократил постановку задачи для простоты. На самом деле: Мне необходимо написать запрос который бы возвращал, скажем, два города с людьми в них проживающих имена которых содержат букву "a" . Т.е. если в городе Х нет людей с буквой "a", то возвращать город не надо. Поверх этого, как я ранее говорил, нужно пагинация. Как-то так.Добавьте это условие в ON-секцию вашего джойна. Джойн же "внутренний" - если людей на букву "А" в городе нет, город и не вернется в результат запроса... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 10:15 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
Щукина АннаДобавьте это условие в ON-секцию вашего джойна. тогда может вернуться меньше двух city, несмотря на наличие городов с жителями 'а'. вместо limit тогда использовать подзапрос с dense_rank. И, в зависимости от того, нужны ли все жители или только 'а', - first_value, max или прочую аналитику для размножения результатов критерия на все строки города. Впрочем по производительности это может оказаться дороже второго обращения к person. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 11:30 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
p2., Спасибо, надо будет въехать в window functions сначала. Посмотрю сегодня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.07.2015, 12:08 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
p2., Почитал, но так и не смог прикрутить dense_rank. Кроме того, постгрес ругается на max(dense_rank...): aggregate function calls cannot contain window function calls. Не могли бы вы немного более развернуто описать как можно решить проблему с использованием dense_rank? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 11:37 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaill, а что вам мешает проверять наличие -- exists -ом, а вывод осуществлять как и раньше. с большой вер-ю exists будет дешёвым. правда от пагинации оффсетом я бы уходил [нужен индекс по (cityid,lastname,id[уникализирующее]) ]. если вы берете клиентом следующую страничку -- листать первую страницу от достигнутого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 19:16 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
qwwq, Если я вас правильно понял, то в этом случае будет что-то вроде: SELECT * FROM City c JOIN Person p ON (c.id=p.CityId) WHERE exists (SELECT * FROM Person p WHERE p.name LIKE '%a%') OFFSET ??? LIMIT ??? хотя я наверное вас не правильно понял, тк этот подход не решает проблему ( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 11:04 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaill, торопицца ненада, да по полочкам: сначала возьмите 2 и только 2 сити (по p2), в которых EXISTS() потом возьмите джойн на персоны, с лимитом и оффсетами. так понятно ? или мало разжевать -- ещё и побуквенно записать модификацию вот этого вот 17888271 требуется ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 11:50 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
qwwq, Не понятно, разжуете? Когда сделаю джойн "проверенных esists-ом" записей с Person, количество записей в результате этого джойна неизвестно (тк city <-> person 1:N). Что вы напишете в LIMIT/OFFSET? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 15:03 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaillqwwq, Не понятно, разжуете? Когда сделаю джойн "проверенных esists-ом" записей с Person, количество записей в результате этого джойна неизвестно (тк city <-> person 1:N). Что вы напишете в LIMIT/OFFSET? Совершенно очевидно помоему. 1)сначала выбираем нужные нам города Код: plsql 1. 2)потом по этим городам выбираем всех персон Код: plsql 1. Собственно все. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 16:46 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Согласен с вами, и это единственное решение которое я смог найти на данный момент: bemtaill... Есть идеи как все это замутить с использованием вложенного SELECT, но коряво это. Наверняка есть более элегантное решение? ... Проблема в том что эти SQL запросы генерятся автоматически Java приложением на основе некого domain-specific language и в реальности и без вложенного селекта выглядят пугающе. Проблема с этим вложенным селектом в том что придется дублировать "WHERE p1.name LIKE '%a%'" (в реальном кэйсе это может быть WHERE с 10-30 термами). Все это продублированное в перемешку с джойнами, сортировками и тд делает такие запросы не сложными для понимания и дебага в случае проблем. Вот тут была идея с подзапросом с dense_rank, но в силу своего слабоумия я так и не понял как ее прикрутить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 17:45 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaill, * сложными ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 17:45 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaillMaxim Boguk, Согласен с вами, и это единственное решение которое я смог найти на данный момент: bemtaill... Есть идеи как все это замутить с использованием вложенного SELECT, но коряво это. Наверняка есть более элегантное решение? ... Проблема в том что эти SQL запросы генерятся автоматически Java приложением на основе некого domain-specific language и в реальности и без вложенного селекта выглядят пугающе. Проблема с этим вложенным селектом в том что придется дублировать "WHERE p1.name LIKE '%a%'" (в реальном кэйсе это может быть WHERE с 10-30 термами). Все это продублированное в перемешку с джойнами, сортировками и тд делает такие запросы не сложными для понимания и дебага в случае проблем. Вот тут была идея с подзапросом с dense_rank, но в силу своего слабоумия я так и не понял как ее прикрутить. чтобы не дублировать условия можно через WITH сделать (и скорее всего это будет быстрее в итоге) Код: plsql 1. 2. при этом вторая часть вообще на зависит от начальных условий. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 18:05 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Выглядит секси:) Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 18:15 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
bemtaillMaxim Boguk, Выглядит секси:) Спасибо! Надо понимать что в общем случае на большой базе такая постановка задачи вообще не имеет хорошего решения от слова совсем. Так что если там у вас десятки миллионов Person и популярный фильтр (под который много людей попадает) - все будет очень медленно. Впрочем постановка " вместе с всеми людьми которые в них проживают" - она гарантированно будет давать медленный ответ на больших городах. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2015, 05:36 |
|
||
|
Запрос с join и pagination
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, если вы стали модератором -- это не значит, что вы в состоянии оценить , что технически важно, а что -нет. более того , мы уже выяснили в одной из задач [про txid и mod 32], что я болван, а вы с мишей -- так вообще образцовые дятлы. это печально. но факт. т.ч. потрудитесь в следующий раз оставить автограф о своей проф-непригодности как модератора. чтобы я вас с кем-то не путал. заранее спасибо. PS единственное, что я пытался донести до ТС -- что он решает не ту задачу и не в той постановке. К удалённой профнепригодным модером модели (если кто-то потрудится её восстановить -- будет замечательно): допустим у нас имеется исчерпывающий справочник имён. И индекс по Сити-персонам. Тогда сразу появляется возможность взять выборку содержащих "буковку" имен от справочника (он уже "дистинкнутый"), далее взять те сити, где EXISTS(имена из фильтрованного списка) [ -- вдоль упомянутого индекса, если кто не заметил], и далее взять простую выборку с LIMIT вдоль того же индекса. Или если мы , помня , что имена небольшие, построим gist/gin индекс по массивам их буковок (что затратно, конечно) -- мы сразу получаем возможность брать быстрый exists, но страничку придется строить с блекд фильтрами и сортировкой (если нет того самого индекса по (city,person)) до того как взять оффсеты и лимит ну и т.п. т.е. в большинстве случаев, когда мы позаботились о внятной организации хранения, задачу фильтрации "городов" можно решить запросом на сущ-е [как правило -- однократным index seek] с использованием того или иного индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.07.2015, 08:52 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39017995&tid=1997859]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
187ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 264ms |
| total: | 545ms |

| 0 / 0 |
