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

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

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

Как составить запрос к базе [D7, FB 2]

Страницы: < 1 2 3 4 5 6 >
OtherSie © (2009-04-23 22:29:00)
Есть 2 таблицы. 1-я - справочник. Содержит в себе список работников и первичный ключ. Вторая - список заказов с прикреплёнными к ним работниками. Содержит 4 поля - внешние ключи - ссылки на первичный ключ первой таблицы и 5-е поле - первичный ключ заказов.

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

Как сделать с хранимой процедурой с четырьмя подзапросами - знаю.

Можно ли как-то выполнить задачу одним запросом? Спасибо.

Кщд (2009-05-05 07:16:00) [41]
>PEAKTOP © (04.05.09 16:57) [59]
>В Firebird это может аукнуться. Например, генеришь IBExpert-ом тестовых >записей миллиона два-три, чтобы скучно ему не было. Выполняешь скрипт - >вроде и план правильный подхватился. А потом на реальных данных "вес" >индекса другой получается, т.к реальные данные далеко не равномерно >распределенные случайные величины
именно так
это справедливо и для Oracle, и для MS SQL
правильная структура данных, грамотное индексирование, сбор статистики - рецепт эффективной БД
хинты уместны, как и говорил ANB, для разовых выборок, отчетов
хинт в серверном коде - зло

Кщд (2009-05-05 07:11:00) [42]
>ANB (04.05.09 15:15) [58]
>Чисто теоретически, есно, возможны расхождения. Пока не нарывался.
в любой сколько-нибудь "тяжелой"(миллионники, запутанная логика в SQL) системе - это данность

>Иначе и смысла бы в он-лайн просмотре планов бы не было.
большого смысла и нет
explain plan - это средство первой линии диагностики - поверхностной и приблизительной

sniknik (2009-05-04 20:03:00) [43]
> Пытаться уже очень давно стоит.
> http://delphiplus.org/articles/ib/firebird-2-full-capability/1/index.html
и где ты там увидел синтаксис access или mssql? или не понятен смысл сказанного?

у mssql нет first, для access используется инструкция transform. для обоих, не обязательно (в одном случае даже нельзя подобную) делать процедуру, проще ограничится запросом. для access вложенные подзапросы группируются не так.

а то, что в FB это как то возможно, так вроде ничего в моем высказывании этому не противоречит.

PEAKTOP (2009-05-04 16:57:00) [44]
>sniknik © (24.04.09 11:08) [23]
> не, конечно и там среди бухгалтеров попадаются отщепенцы,
> придумали такую вещь как шахматка... но и ее делают. чаще
> всего "поворачивая" полученный результат на клиенте, делая
> из "высоты" "ширину". можно и на сервере, легко могу сделать
> на access или mssql но на FB боюсь их синтаксис не пройдет,
> даже не пытаться не стоит (а трудов чтобы разбираться задача
> не стоит. глупая логика).

Пытаться уже очень давно стоит.
http://delphiplus.org/articles/ib/firebird-2-full-capability/1/index.html

> ANB (29.04.09 14:55) [48]
> Если оптимизатор сразу дает примерно правильный план - я и не хинтую.

В Firebird это может аукнуться. Например, генеришь IBExpert-ом тестовых записей миллиона два-три, чтобы скучно ему не было. Выполняешь скрипт - вроде и план правильный подхватился. А потом на реальных данных "вес" индекса другой получается, т.к реальные данные далеко не равномерно распределенные случайные величины, как в генераторе IBExpert-a. И план твоего запроса (имеется в виду внутри ХП) после первого backup/restore "поедет" куда-то. Так что все-таки бывают случаи, когда планы иногда надо указывать явно. Лично у мну есть пример запроса с "дефолтным" планом, выполняющийся за 18 секунд, и "ручным", выполняющимся за миллисекунды.

Зато при переходе от версии к версии (как это было при 1.5 -> 2.0) есть вероятность наступить на очень древние грабли с изменениями в оптимизаторе, когда твоя БД тупо не восстанавливается из бэкапа из-за кривых (по мнению новой версии) статически прописанных планов. И тогда начинается увлекательнейший квест с перелопачиванием штук 800-1000 хранимых процедур. Так что тут есть свои и плюсы и минусы.

Есть еще третий, компромиссный вариант: хинты. Например, когда индексное поле попадает в условие WHERE, то к нему можно прибавлять 0, дабы отключить использование индекса. Такой изврат на данный момент времени дает похожий план запроса на разных версиях оптимизатора.

ANB (2009-05-04 15:15:00) [45]

> реальный план можно увидеть только в трейсе
> может случиться так, что Вы хинтами оптимизируете пустоту

Ну ни разу еще не нарывался. Как задумано - так и работает.

Если план по Ф5 показывает ерунду - запрос висит. Если показывает то, что надо - работает.

Чисто теоретически, есно, возможны расхождения. Пока не нарывался.
Иначе и смысла бы в он-лайн просмотре планов бы не было.

Кщд (2009-05-04 10:18:00) [46]
>ANB (04.05.09 09:57) [55]
>F5 в девелопере
реальный план можно увидеть только в трейсе
может случиться так, что Вы хинтами оптимизируете пустоту

Кщд (2009-05-04 10:17:00) [47]
>Игорь Шевченко © (30.04.09 14:06) [54]
>Вот что странно - за долгую и многотрудную жизнь ни разу не приходилось >сталкиваться с необходимостью составлять подобные запросы.
очень редко, но случалось, поэтому сейчас, когда oracle залатал баги, связанные с join, пишу в join-синтаксисе
собственно, против (+)-синтаксиса ничего против не имею

ANB (2009-05-04 09:57:00) [48]

> каким образом смотрите план?

F5 в девелопере

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

Я сталкивался. Когда сталкивался - тогда и писал другим синтаксисом. Но это так редко бывает . . .

Игорь Шевченко (2009-04-30 14:06:00) [49]

> ORA-01719: оператор внешнего соединения (+) не разрешен
> в операндах OR или IN

Уел :)

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

Кщд (2009-04-30 09:17:00) [50]
>Игорь Шевченко © (29.04.09 19:17) [52]
затруднит)
SQL> select t.*, t2.* 2 from tmp t, tmp2 t2 3 where t.id = t2.id(+) 4 or t.id2 = t2.id2(+) 5 ; ORA-01719: оператор внешнего соединения (+) не разрешен в операндах OR или IN
собственно, об этом и говорил

или ещё пример:
как переписать на (+)-синтаксисе такой запрос
select t.*, t2.* from tmp t left join tmp2 t2 on t.id = t2.id and t.id2 = 2

Игорь Шевченко (2009-04-29 19:17:00) [51]
Кщд (29.04.09 14:56) [49]

А планы в студию для обоих вариантов не затруднит ?

Anatoly Podgoretsky (2009-04-29 16:16:00) [52]
> ANB (29.04.2009 14:55:48) [48]

А если не сразу, а потом, и при этом для обеих случаев, кроме того как выяснили мешает независимому администрированию.

Кщд (2009-04-29 14:58:00) [53]
>ANB (29.04.09 14:55) [48]
>Если оптимизатор сразу дает примерно правильный план - я и не хинтую.
каким образом смотрите план?

Кщд (2009-04-29 14:56:00) [54]
>Игорь Шевченко © (27.04.09 15:01) [41]
>"Три следующих запроса, в первом из которых используется старый >синтаксис, семантически одинаковы:
говорил о случаях, когда не одинаковы)
например,
select t.*, t2.* from tmp t, tmp2 t2 where t.id = t2.id(+) or t.id2 = t2.id2(+) select t.*, t2.* from tmp t left join tmp2 t2 on t.id = t2.id or t.id2 = t2.id2

ANB (2009-04-29 14:55:00) [55]

> Ты пойми простую вещь - я не настаиваю на том, чтобы лично
> ты прекратил пользоваться хинтами, я высказываю свое мнение
> относительно целесообразности использование костылей при
> ходьбе вообще.

Если оптимизатор сразу дает примерно правильный план - я и не хинтую.

Игорь Шевченко (2009-04-29 10:56:00) [56]
ANB (29.04.09 10:11) [46]

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

ANB (2009-04-29 10:11:00) [57]

> Кривое не может сделаться прямым

1) Ради одного отчета никто не будет переделывать БД
2) Даже если структуру БД сделать идеальной, то конвертить туда данные просто нереально.
3) Все равно придется применять хинты в особо сложных случаях - хэш джойн, распараллеливание запросов. Оптимизатор не идеален.

Игорь Шевченко (2009-04-28 15:45:00) [58]

> К сожалению, без них частенько никак

Кривое не может сделаться прямым

ANB (2009-04-28 09:31:00) [59]

> хинты - это зло, зло и зло
>
>
> Воистину

Ну ну. К сожалению, без них частенько никак.
А если админ попытается угробить работающую систему - так у нас их много.
Будет новый главный админ, всего то и делов. :)

ANB (2009-04-28 09:27:00) [60]

> full outer join

Сколько раз в жизни вы им пользовались ?

Страницы: < 1 2 3 4 5 6 >

Наверх

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