Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 3 >
Neo Trinitron © (2006-09-15 15:38:00)
Наверное каждый программист сталкивался с чужими громаднейшими запросами повышеной сложности. У кого какая метода выработалась изучать и понимать такие запросы? Вот сижу и ломаю себе голову: как разобрать запрос на 6 экранов... Вобщем, у кого какая метода?

alex_*** (2006-09-21 16:16:00) [1]
и собирать. и чтоб лишних деталей не осталось

Neo Trinitron (2006-09-21 15:29:00) [2]
Зашёл в темку посмотреть, а тут уже и тема поменялась :) Я разобрал запрос путём графического представления связей, условий, и т.д. Очень получилось наглядно, удобно, понятно. Однако принятые мною правила нотации не стандартны и софта под них нет. Но мне то оно реально помогло! Думаю софт какой-нить слобать который мне поможет в дальнейшем, чтобы не на бумаге и не ручкой. Всем спасибо.

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

Система у нас огромная, построена сравнительно грамотно весьма образоваными и опытными людьми. Разобрав запрос я увидел, что всё было сделано оптимально. Мало того, они ещё и оптимизировали его! Так что огромные запросы могут быть и важно уметь их быстро разбирать.

zdm (2006-09-21 13:47:00) [3]
:)

Petr V. Abramov (2006-09-21 13:45:00) [4]
> zdm © (21.09.06 13:20) [43]
> Мы помоему вообще от вопроса автора отъехали и начали решать личные проблемы, тебе не кажится? :)

кажится :)

zdm (2006-09-21 13:20:00) [5]

> Petr V. Abramov

Мы помоему вообще от вопроса автора отъехали и начали решать личные проблемы, тебе не кажится? :)

Petr V. Abramov (2006-09-21 13:17:00) [6]
> zdm © (21.09.06 13:14) [40]
да какая разница? главное, что соединениес ней идет 2 раза

zdm (2006-09-21 13:15:00) [7]

> Petr V. Abramov

да ладно, помоему уже обсудили тему :)))

zdm (2006-09-21 13:14:00) [8]
а r1 и r2 это у тебя одна таблица???

Petr V. Abramov (2006-09-21 13:13:00) [9]
в моем примере имелся в виду Oracle, т.к возник он (пример :) в рамках полемики с Johnmen © (16.09.06 22:21) [16]

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

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

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

zdm (2006-09-21 13:04:00) [11]

> Petr V. Abramov

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

Petr V. Abramov (2006-09-21 13:00:00) [12]
> 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). Объем сортировки поменяется кардинально. В данном конкретном случае, может, и можно пережить, а вот если таблиц побольше - будет видно невооруженным глазом.

dr Gonzo (2006-09-21 12:24:00) [13]
Мой метод

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

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

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

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

alex_*** (2006-09-21 12:22:00) [14]
>и там зачастую проще написать один сложный, чем на что то его разбывать

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

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

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

alex_*** (2006-09-21 12:12:00) [16]
>Для понимания конкретного запроса менять структуру БД?!!!
Хм. Интересное предложение. Но я бы не стал им пользоваться. 8-)

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

zdm (2006-09-21 12:05:00) [17]
Кстати, даже со своими запросами это прокатывает. Просто иногда---как пошла мысль...пишешь, пишешь, а потом кидаешь на исполнение...и не фига. А разберешь так этот громадненький запрос на кучу маленьких и ошибка сразу видна.

Sergey13 (2006-09-21 12:03:00) [18]
> [26] alex_*** © (21.09.06 11:48)

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

zdm (2006-09-21 12:00:00) [19]
я так думаю, что когда полная "засада" с запросом, нужно сделать следующее.
1. Попытаться разъединить большой запрос на кучу маленьких.
2. Повыполнять эти маленькие подзапросы.
3. Картина становится ясней,, и собрать это всё в кучу.

alex_*** (2006-09-21 11:55:00) [20]
запрос можно будет отладить по частям и понять общую картину. Когда перед тобой простыня с кучей вложенных циклов или разложенный на процедуры код - что лучше читается и понимается?

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »