Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.11.19;
Скачать: CL | DM;

Вниз

Громаднейшие запросы 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]

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


 
zdm ©   (2006-09-21 12:00) [29]

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


 
Sergey13 ©   (2006-09-21 12:03) [30]

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

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


 
zdm ©   (2006-09-21 12:05) [31]

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


 
alex_*** ©   (2006-09-21 12:12) [32]

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

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


 
atruhin ©   (2006-09-21 12:20) [33]

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

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


 
alex_*** ©   (2006-09-21 12:22) [34]

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

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


 
dr Gonzo ©   (2006-09-21 12:24) [35]

Мой метод

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

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

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

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


 
Petr V. Abramov ©   (2006-09-21 13:00) [36]

> 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). Объем сортировки поменяется кардинально. В данном конкретном случае, может, и можно пережить, а вот если таблиц побольше - будет видно невооруженным глазом.


 
zdm ©   (2006-09-21 13:04) [37]


> Petr V. Abramov

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


 
Petr V. Abramov ©   (2006-09-21 13:11) [38]

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

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

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


 
Petr V. Abramov ©   (2006-09-21 13:13) [39]

в моем примере имелся в виду Oracle, т.к возник он (пример :) в рамках полемики с Johnmen ©   (16.09.06 22:21) [16]


 
zdm ©   (2006-09-21 13:14) [40]

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



Страницы: 1 2 вся ветка

Текущий архив: 2006.11.19;
Скачать: CL | DM;

Наверх




Память: 0.57 MB
Время: 0.071 c
1-1160246560
Master_
2006-10-07 22:42
2006.11.19
Вычисление производных в Delphi


3-1158571057
memo
2006-09-18 13:17
2006.11.19
BLOB поле


2-1162723518
Ezorcist
2006-11-05 13:45
2006.11.19
Занят ли порт?


3-1158580205
AW
2006-09-18 15:50
2006.11.19
создание приложения в Delphi для FireBird


15-1162285919
Crazybeaver
2006-10-31 12:11
2006.11.19
Альтернатива FrontPage