Громаднейшие запросы SQL

← →
Neo Trinitron © (2006-09-15 15:38) [0]

Наверное каждый программист сталкивался с чужими громаднейшими запросами повышеной сложности. У кого какая метода выработалась изучать и понимать такие запросы? Вот сижу и ломаю себе голову: как разобрать запрос на 6 экранов... Вобщем, у кого какая метода?

← →
Desdechado © (2006-09-15 15:59) [1]

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

← →
Neo Trinitron © (2006-09-15 16:06) [2]

Гы. Автор ни при чём. Запрос просто сложный, написан неплохо (отступы и прочие правила нотации в хорошем стиле), но целостность картины трудно получить. В идеале представить графически как-то, но как?

← →
Romkin © (2006-09-15 16:10) [3]

1. Идешь на http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=12992
2. Читаешь вопрос и пытаешься понять.
После этого - вполне нормально поймешь, что написано :)

← →
atruhin © (2006-09-15 16:19) [4]

> [3] Romkin © (15.09.06 16:10)

Класс!

← →
Neo Trinitron © (2006-09-15 16:22) [5]

> После этого - вполне нормально поймешь, что написано :)

Ответное предложение:

1. Идёшь на первый пост в этой ветке
2. Читаешь вопрос и пытаешься понять
После этого - вполне нормально поймёшь, что написано :)

← →
Desdechado © (2006-09-15 16:36) [6]

Пытать не просто так, а чтоб узнать, что и как он этим запросом делает.

← →
Sergey13 © (2006-09-15 16:52) [7]

> [0] Neo Trinitron © (15.09.06 15:38)

Пытаться упростить запрос выделяя подзапросы и прочие логические куски, пытаясь уловить общую идею. Потом по частям разбираться. Я так обычно.

← →
Neo Trinitron © (2006-09-15 17:14) [8]

Sergey13 © , у меня такая же метода, тока я это пытаюсь представить графически. Вышеописаный запрос я разобрал за 3 часа. Не знаю на сколько это медленно/быстро. Мой начальник описал его с помощью теории множеств. Блин, глянул на его работу, вспомнил что такое настоящий страх. Мало того что значков полно, ещё это дело и на 15 листов получилось:)

← →
ANB © (2006-09-15 17:34) [9]

> Neo Trinitron © (15.09.06 17:14) [8]

Ты, часом, не в МВ работаешь ? Там любили писать многокилобоайтные запросы . . .

← →
Neo Trinitron © (2006-09-15 17:47) [10]

> Ты, часом, не в МВ работаешь ? Там любили писать многокилобоайтные запросы . . .

Не, даже не знаю такой конторы. Но запрос, поверьте, действительно не простой и упростить его нельзя. Он возвращает 37 полей, в критериях 23 условия, 15 таблиц...Така жопа...

← →
Desdechado © (2006-09-15 17:51) [11]

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

← →
Neo Trinitron © (2006-09-15 18:14) [12]

Desdechado ©, этот запрос как раз и находится в ХП. И от этого он не становится проще и поделить его нельзя. Логику не упростишь. Сначала делали так, потом подумали что нужно добавить кое-чего. Так системы и разростаются. Надстройки, мать их... Согласен что такие запросы есть изврат, но я же не буду рассказывать начальнику что надо переписать программу...

← →
Desdechado © (2006-09-15 19:03) [13]

Имхо, нет ни одного запроса (в котором джойнится более одной таблицы), который нельзя разбить на два и задействовать их в ХП.

← →
Anatoly Podgoretsky © (2006-09-15 19:44) [14]

Neo Trinitron © (15.09.06 15:38)
Ну какой же это сложный запрос, MS SQL поддерживет до 256 мегабайт

← →
ANB © (2006-09-15 19:46) [15]

> Он возвращает 37 полей, в критериях 23 условия, 15 таблиц.
> ..Така жопа...

Ээээ. Таки его точно можно сделать меньше.

← →
Johnmen © (2006-09-16 22:21) [16]

Если появляется НАСУЩНАЯ НЕОБХОДИМОСТЬ строить многоэтажные запросы, то это говорит только об одном - неграмотно спроектированной структуре БД.
Не имхо.

← →
Petr V. Abramov © (2006-09-19 23:25) [17]

> Johnmen © (16.09.06 22:21) [16]
в Oracle это может повысить скорость, может просто избавить от геморроя.

> Он возвращает 37 полей, в критериях 23 условия, 15 таблиц...Така жопа...
фигня, хотя не ежедневная. хотя для чего-то, кроме анализа - точно така

> как разобрать запрос на 6 экранов... Вобщем, у кого какая метода?
0. узнать, для чего он нужен. если никто не знает - забить
1. задача сводится к пониманию, почему сделано так, ане иначе

← →
SergP © (2006-09-19 23:43) [18]

> [16] Johnmen © (16.09.06 22:21)
> Если появляется НАСУЩНАЯ НЕОБХОДИМОСТЬ строить многоэтажные
> запросы, то это говорит только об одном - неграмотно спроектированной
> структуре БД.
> Не имхо.

видел ПО где запросы формируются програмно, и в результате достигают несколькокилобайтного размера. Разве в таком случае можно говорить о неправильно спроектированной структуре БД?

← →
Petr V. Abramov © (2006-09-20 00:42) [19]

> SergP © (19.09.06 23:43) [18]
говорит о том, что или или вместе
грамотная структура
грамотный формирователь
самое грусное, никто не пользуется :)

← →
Desdechado © (2006-09-20 12:19) [20]

Petr V. Abramov © (19.09.06 23:25) [17]
> в Oracle это может повысить скорость, может просто избавить от геморроя.
А можети наоборот - завалить скорость и вырастить геморрой у тех, кто будет разбирать эти запросы, особенно с целью выяснить, что же было причиной завала скорости.

← →
ЮЮ © (2006-09-20 12:37) [21]

> Он возвращает 37 полей, в критериях 23 условия, 15 таблиц.

Сведи к

SELECT
t1.f as AAA,
...
t15.f as YYY
FROM
aaaaaaaa t1
JOIN bbbbb t2 ON ...
...
JOIN kkkkkk t15 ON ...
WHERE
(t1.f = ...) AND
...
(t15.f = ...)

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

И чего тут разбираться? Откуда 6 экранов? 78 строк всего :)

← →
alex_*** © (2006-09-21 11:07) [22]

а часть логики перенести во view

← →
zdm © (2006-09-21 11:17) [23]

а не проще-ли поюзать какие-нибдь проги, типа для Or-ы pl/sql developer, или для IB/FB -IBExpert , там есть форматирование SQL запроса..

← →
zdm © (2006-09-21 11:19) [24]

> И чего тут разбираться? Откуда 6 экранов? 78 строк всего
> :)

Действительно

← →
Sergey13 © (2006-09-21 11:44) [25]

> [22] alex_*** © (21.09.06 11:07)

И что это даст?

← →
alex_*** © (2006-09-21 11:48) [26]

>И что это даст?
часть join"ов, cast"ов, where уйдет во VIEW

← →
zdm © (2006-09-21 11:52) [27]

> >И что это даст?
> часть join"ов, cast"ов, where уйдет во VIEW

и что? с самим запросом ему легче не станет! я так понял что автору, просто трудно разобраться с самим запросом, или не грамотным его форматированием, а перенос во VIEW, да еще когда он до конца не понял самого запроса, запутает его в конец.

← →
alex_*** © (2006-09-21 11:55) [28]

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

я так думаю, что когда полная "засада" с запросом, нужно сделать следующее.
1. Попытаться разъединить большой запрос на кучу маленьких.
2. Повыполнять эти маленькие подзапросы.
3. Картина становится ясней,, и собрать это всё в кучу.

> [26] alex_*** © (21.09.06 11:48)

Для понимания конкретного запроса менять структуру БД?!!!
Хм. Интересное предложение. Но я бы не стал им пользоваться. 8-)

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

>Для понимания конкретного запроса менять структуру БД?!!!
Хм. Интересное предложение. Но я бы не стал им пользоваться. 8-)

я же не предлагаю таблички менять

> [31] zdm © (21.09.06 12:05)
> Просто иногда---как пошла мысль...пишешь, пишешь,

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

>и там зачастую проще написать один сложный, чем на что то его разбывать

:) потом сложно в нем разбираться. Для отчетов какие-то особые запросы чтоль?

Мой метод

а) сначала вникнуть в структуру БАЗЫ, можно даже поверхностно. просто уяснить где справочники, где хранилища, пробежаться по View и функциям.
Если база с большим кол-во таблиц, то посмотреть хотя бы ту часть которая используется с запросе.

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

в) собственно обычно реально "рабочие" бывают 2-3 таблицы.

г) еще очень помогает анализировать отдельно подзапросы.

> Desdechado © (20.09.06 12:19) [20]
приведи пример, как select from select сможет снизить скорость?
пример, когда может повысить:

select sum(t.summa), r1.name, r2.name
from t1 /* тут миллилоны записей */,
r1 /* это какой-нить справочник с name varchar2 под 50-100 */
r2 /* это какой-нить справочник с name varchar2 под 50-100 */
where t1.id1 = r1.id
and t1.id2 = r2.id
group by r1.name, r2.name

а можно сначала просуммировать, группируя по id1, id2, а во внешнем подзапросе уже соединить со справочниками (r1 и r2). Объем сортировки поменяется кардинально. В данном конкретном случае, может, и можно пережить, а вот если таблиц побольше - будет видно невооруженным глазом.

> Petr V. Abramov

select from select всегда понизит скорость, а группировка по нескоильким таблицам тем-более

> Petr V. Abramov © (21.09.06 13:00) [36]
кстати, и cardinality join`а - тоже

> zdm © (21.09.06 13:04) [37]
> select from select всегда понизит скорость,
может, мы просто о разных СУБД говорим? хотелось бы надеяться :)

> а группировка по нескоильким таблицам тем-более
а что такое "группировка по нескоильким таблицам"? группируют по полям

а r1 и r2 это у тебя одна таблица???

Громаднейшие запросы SQL Найти похожие ветки