| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как составить запрос к базе [D7, FB 2]
OtherSie © (2009-04-23 22:29:00)Есть 2 таблицы. 1-я - справочник. Содержит в себе список работников и первичный ключ. Вторая - список заказов с прикреплёнными к ним работниками. Содержит 4 поля - внешние ключи - ссылки на первичный ключ первой таблицы и 5-е поле - первичный ключ заказов.
Нужно выбрать фамилии из первой таблицы по запросу нужного значения первичного ключа во второй таблице.
Как сделать с хранимой процедурой с четырьмя подзапросами - знаю.
Можно ли как-то выполнить задачу одним запросом? Спасибо.
Игорь Шевченко (2009-04-27 15:02:00) [61]
> хинты - это зло, зло и зло
Воистину
Игорь Шевченко (2009-04-27 15:01:00) [62]Кщд (27.04.09 14:53) [39]
> так, вообще говоря, (+) не эквивалентен left/right outer
> join
"Три следующих запроса, в первом из которых используется старый синтаксис, семантически одинаковы:
SELECT c.course_name, c.period,
e.student_name
FROM course c, enrollment e
WHERE c.course_name = e.course_name(+)
AND c.period = e.period(+);
SELECT c.course_name, c.period,
e.student_name
FROM course c LEFT OUTER JOIN enrollment e
ON c.course_name = e.course_name
AND c.period = e.period;
SELECT c.course_name, c.period,
e.student_name
FROM enrollment e RIGHT OUTER JOIN course c
ON c.course_name = e.course_name
AND c.period = e.period;
"
http://www.oracle.com/global/ru/oramag/march2002/dev_ansi.html
> да и (+)-синтаксис при необходимости full outer join не
> слишком спасает)
не спасает. Когда требуется full outer join ставится full outer join. Беда только в том, что редко требуется :)
Кщд (2009-04-27 14:55:00) [63]>ANB (27.04.09 13:55) [38]
>Если у меня хинт ordered и я начинаю играть порядком обхода, то при >неявном объединении мне надо будет только поменять местами >таблицы во фроме (вырезать+вставить). А при явном - переделывать >текст запроса.
а потом, например, dba врубает plan stability, и вся система идет под откос
хинты - это зло, зло и зло)
Кщд (2009-04-27 14:53:00) [64]>Игорь Шевченко © (27.04.09 12:02) [37]
>А я до сих пор в оракле (+) пишу - оно как-то понятнее и серверу и мне и моим коллегам
так, вообще говоря, (+) не эквивалентен left/right outer join
да и (+)-синтаксис при необходимости full outer join не слишком спасает)
ANB (2009-04-27 13:55:00) [65]
> А я до сих пор в оракле (+) пишу - оно как-то понятнее и
> серверу и мне и моим коллегам
Вот и я о том же.
> скопипастить 40 символов намного труднее чем 10?
Если у меня хинт ordered и я начинаю играть порядком обхода, то при неявном объединении мне надо будет только поменять местами таблицы во фроме (вырезать+вставить). А при явном - переделывать текст запроса.
А пониманию больше способствует аккуратное форматирование запросов. Потому как кашу из явных джойнов тоже задерешься разгребать.
Игорь Шевченко (2009-04-27 12:02:00) [66]А я до сих пор в оракле (+) пишу - оно как-то понятнее и серверу и мне и моим коллегам
Anatoly Podgoretsky (2009-04-27 11:53:00) [67]> sniknik (27.04.2009 10:25:35) [35]
Что там первисив, в Оракле не было.
sniknik (2009-04-27 10:25:00) [68]> С явными джойнами надо запрос посильнее править.
> Да и букав писать больше.
скопипастить 40 символов намного труднее чем 10?
> 1) Больше вариантов объединения
?
вообще то от синтаксиса конкретного sql сервера зависит, например когда то в первисиве не было синтаксиса явных объединений, но никаких ограничений на их варианты не было, лефт джойн делался += , райт =+ , полное объединение * (или *= с любой стороны, не помню).
дело вовсе не в вариантах, дело в том что ты пишешь так как это понимает sql сервер, т.е. вы говорите на одном языке. это способствует пониманию.
с неявными, могут написать и даже не понять что сделали объединение... ни о каком понимании и речи нет.
ANB (2009-04-27 10:08:00) [69]
> дело привычки. тем более когда понимаешь их логику то оптимизировать
> уже не приходится, сразу пишешь оптимально. а вот в неявных
> черт ногу сломит, а иногда и sql ый парсер понимает их по
> разному.
явными хорошо, если ты уже знаешь оптимальный план.
А вот если ты его подбираешь, то частенько вылезает необходимость поменять порядок обхода таблиц. С явными джойнами надо запрос посильнее править.
Да и букав писать больше.
У явных джойнов мне нравятся 2 вещи :
1) Больше вариантов объединения (правда "лишние" варианты весьма экзотические и фулл оутер я всего раз в жизни применял на практике).
2) Труднее забыть про связки и нарваться на картезиан.
Виталий Панасенко(дом) (2009-04-25 19:14:00) [70]Удалено модератором
OtherSie (2009-04-25 17:16:00) [71]Удалено модератором
AndreyV (2009-04-25 17:13:00) [72]> [28] OtherSie (25.04.09 16:44)
Ни хочешь слушать советы - твоё право. Но зачем тогда спрашивал, напрягал людей, заметь - бесплатно?
OtherSie (2009-04-25 16:47:00) [73]Особенно когда эта оптимизация утяжеляет решение в разы...
OtherSie (2009-04-25 16:47:00) [74]Не давая никакого практического выигрыша.
OtherSie (2009-04-25 16:44:00) [75]Сниксника пора судить за стрельбу из пушек по воробьям. Не каждая задача требует абсолютной оптимизации.
MsGuns (2009-04-25 14:57:00) [76]Сникника пора судить за растрату бисерного фонда :)
sniknik (2009-04-24 12:35:00) [77]> Зато с ними тяжелее оптимизить запросы.
дело привычки. тем более когда понимаешь их логику то оптимизировать уже не приходится, сразу пишешь оптимально. а вот в неявных черт ногу сломит, а иногда и sql ый парсер понимает их по разному.
> Вроде бы никакой крамолы нет.
4 объединения в любом случае, даже самом оптимистичном, в 4 раз медленнее чем одно. при том же результате, только в непривычном для тебя виде.
> Далее, в случае необходимости, будем оптимизировать базу.
не получится. далее тебе ее придется переделывать с 0.
> Пока ограничимся имеющимся запросом.
вольному воля.
OtherSie (2009-04-24 12:15:00) [78]
> И это всё, что ты увидел в ответе, хотя об этом в нём не
> говорилось.
Я собственно это и говорил - что алисов не увидел - сам нашел.
> кто ж знал, что ты не знаешь про псевдонимы, про которые
> пишут на 15-20 й странице любого учебника по sql.
Век живи, век учичись, всё равно дураком помрёшь. Базы я знаю плохо - с этим спорить не буду.
Посмотрел по планам/использованию индексов/анализу производительности. Вроде бы никакой крамолы нет. Индексы по ключам используются. Натуральных планов нет. Из таблиц количество чтений минимально достаточное для того, что бы отдать данные.
Вроде бы никакой крамолы. Во всяком случае, пока...
200, как и 1000 человек, думаю, никак не повлияют на скорость. 200 джобов, думаю, там не будет никогда. Далее, в случае необходимости, будем оптимизировать базу. Пока ограничимся имеющимся запросом.
Всем спасибо за ответы.
ANB (2009-04-24 12:07:00) [79]
> (join-ы это тоже хорошая фича, про которую ты наверное не
> знаешь, и рекомендуемая к использованию т.к. она ближе к
> тому как работает sql сервер, больше способствует пониманию,
> чем неявные объединения)
Зато с ними тяжелее оптимизить запросы.
sniknik (2009-04-24 11:08:00) [80]> Имелось в виду, что нашел, что у таблиц могут быть алиасы. Хорошая фича.
кто ж знал, что ты не знаешь про псевдонимы, про которые пишут на 15-20 й странице любого учебника по sql. и проблему ты видишь только в этом...
я вот вижу у тебя проблему в нежелании работать со списками, непонимании логики баз. а вовсе не в алиасах.
кстати, у твоего подхода есть минус, кроме того что там полей не напасешься, ну вот представь, что после будет например 200 человек... 200 полей, и 200 объединений таблицы самой с собой, вместо одно... это хороший способ поставить "на колени" любой sql сервер. даже четыре могут тормозить при определенных условиях. (размер таблиц/отсутствие или невозможность использование индексов)
вот запиши объединение в явном виде, с помощью join-ов сразу поймешь что имеется в виду. (join-ы это тоже хорошая фича, про которую ты наверное не знаешь, и рекомендуемая к использованию т.к. она ближе к тому как работает sql сервер, больше способствует пониманию, чем неявные объединения)
| |
Страницы: 