Как составить запрос к базе

← →
OtherSie (2009-04-23 22:29) [0]

Есть 2 таблицы. 1-я - справочник. Содержит в себе список работников и первичный ключ. Вторая - список заказов с прикреплёнными к ним работниками. Содержит 4 поля - внешние ключи - ссылки на первичный ключ первой таблицы и 5-е поле - первичный ключ заказов.

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

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

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

← →
sniknik © (2009-04-23 23:06) [1]

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

хочу знать способ. заинтриговал чертяка. а то одним запросом это как то банально и мелко...

← →
turbouser © (2009-04-23 23:13) [2]

> sniknik © (23.04.09 23:06) [1]

А то! Хочу энто видеть !

← →
AndreyV © (2009-04-23 23:25) [3]

> [1] sniknik © (23.04.09 23:06)
> хочу знать способ. заинтриговал чертяка. а то одним запросом
> это как то банально и мелко...

Бартер?

← →
OtherSie (2009-04-23 23:45) [4]

Как-то так:

create procedure NEW_PROCEDURE ( TEST_UID integer) returns ( FIO1 char(10), FIO2 char(10), FIO3 char(10), FIO4 char(10)) as begin select VOC_CONTANT from VOCAB, TEST where TEST.TEST_UID = :TEST_UID and VOCAB.VOC_UID = TEST.TEST1 into :FIO1; select VOC_CONTANT from VOCAB, TEST where TEST.TEST_UID = :TEST_UID and VOCAB.VOC_UID = TEST.TEST2 into :FIO2; select VOC_CONTANT from VOCAB, TEST where TEST.TEST_UID = :TEST_UID and VOCAB.VOC_UID = TEST.TEST3 into :FIO3; select VOC_CONTANT from VOCAB, TEST where TEST.TEST_UID = :TEST_UID and VOCAB.VOC_UID = TEST.TEST4 into :FIO4; suspend; end select * from NEW_PROCEDURE(1)

Возвращает то, что мне нужно.

← →
OtherSie (2009-04-23 23:47) [5]

Можно ли как-то компактнее сделать?

← →
sniknik © (2009-04-24 00:23) [6]

т.е. тебе нужно вот это
select VOC_CONTANT
from VOCAB, TEST
where TEST.TEST_UID = 1 and
(VOCAB.VOC_UID = TEST.TEST1 or
VOCAB.VOC_UID = TEST.TEST2 or
VOCAB.VOC_UID = TEST.TEST3 or
VOCAB.VOC_UID = TEST.TEST4)
должен выдать список из 4х полей.

← →
sniknik © (2009-04-24 00:28) [7]

но вообще, так не делается, соединяют обычно по одному полю, потому как располагают данные в "высоту" таблицы, а не "ширину" тогда и количество этих данных не будет ограничено 4-мя... да и работать удобнее.

← →
OtherSie (2009-04-24 00:50) [8]

> т.е. тебе нужно вот это select VOC_CONTANT

> должен выдать список из 4х полей.

Запрос выдаст только одно поле. И 4 условия лишние.

> но вообще, так не делается, соединяют обычно по одному полю, потому как располагают данные в "высоту" таблицы, а не "ширину" тогда и количество этих данных не будет ограничено 4-мя... да и работать удобнее.

Если бы удалось выполнить задачу одним запросом - можно было бы отдавать в качестве результата множество записей. Сейчас BETWEEN никак не напишешь, конечно.

Как вообще делается я знаю. Можно было бы предложить сделать четыре справочника вместо одного. Тогда, конечно, никаких проблем бы не было. Но, дело в том, что одни и те же люди могут входить в разные справочники одновременно (поля TEST1 - TEST4 - это, как я поняли из задания, специальности, необходимые для выполнения задания. они у разных людей могут пересекаться). Поэтому добавление еще трёх справочников приведёт к явной денормальзации базы.

← →
OtherSie (2009-04-24 00:52) [9]

> апрос выдаст только одно поле. И 4 условия лишние.

Сорри, проглючило :) or не увидел. Буду тестить. Возможно - самое то...

← →
Игорь Шевченко © (2009-04-24 00:54) [10]

> (поля TEST1 - TEST4 - это, как я поняли из задания, специальности,
> необходимые для выполнения задания. они у разных людей
> могут пересекаться).

такой глупый вопрос - а если для выполнения задания потребуется, не дай Аллах, пять специальностей ?

Вроде как примеров с Job и Skill в любом учебнике по SQL навалом - бери да переписывай любой.

← →
OtherSie (2009-04-24 00:56) [11]

Ыыыы.... Не то. Таки да - вернулось же много записей с одним полем. И Between-то работает, но не так, как нужно. ХП то как раз возвращает одну запись с четырьмя полями... Но - слишком сложно и только для одного uid"а...

← →
OtherSie (2009-04-24 01:02) [12]

> такой глупый вопрос - а если для выполнения задания потребуется,
> не дай Аллах, пять специальностей ?

Ну и хорошо - добавят еще одно поле (допустим - TEST5), в джобы - нужных людей, у которых есть нужный скилл.

> Вроде как примеров с Job и Skill в любом учебнике по SQL
> навалом - бери да переписывай любой.

Порылся - сходу не нашел. Самому как-то такие задачи не попадались ранее.

← →
OtherSie (2009-04-24 01:43) [13]

Нашел таки :)

select TABL1.VOC_CONTANT, TABL2.VOC_CONTANT, TABL3.VOC_CONTANT, TABL4.VOC_CONTANT from VOCAB TABL1, VOCAB TABL2, VOCAB TABL3, VOCAB TABL4, TEST where TEST.TEST_UID between 1 and 2 and TABL1.VOC_UID = TEST.TEST1 and TABL2.VOC_UID = TEST.TEST2 and TABL3.VOC_UID = TEST.TEST3 and TABL4.VOC_UID = TEST.TEST4

Не видел раньше алиасов у таблиц :)

← →
sniknik © (2009-04-24 01:56) [14]

> Ну и хорошо - добавят еще одно поле (допустим - TEST5), в джобы - нужных людей, у которых есть нужный скилл.
может сразу тогда этим людям дать программу писать? которые будут твое творение править. у них наверняка лучше получится (лень заставит. как пару раз что нибудь вылезет на поправку когда уже все, что делалось забыл, так сразу научатся головой работать а не руками).

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

например простая накладная - справочник товаров + справочник документов, отбрасываем разные отвлекающие поля вроде типа накладной, цен товаров для записей, и т.д. оставляем только названия товаров и id для связей как у тебя.
остается - поле с номером накладной, и поле связи по id со справочником товаров. в "высоту" прошу заметить, никому в голову не приходит для каждой накладной, полей в "ширину" добавлять, если вдруг товаров больше пришло. и все. по этим двум полям все находится, все записи накладной, по ее номеру, все названия товаров из присоединенного по полю связи справочника. и все в "высоту". так удобнее.
не, конечно и там среди бухгалтеров попадаются отщепенцы, придумали такую вещь как шахматка... но и ее делают. чаще всего "поворачивая" полученный результат на клиенте, делая из "высоты" "ширину". можно и на сервере, легко могу сделать на access или mssql но на FB боюсь их синтаксис не пройдет, даже не пытаться не стоит (а трудов чтобы разбираться задача не стоит. глупая логика).

← →
Германн © (2009-04-24 02:04) [15]

> sniknik © (24.04.09 01:56) [14]

Количество двойных кавычек превысило все разумные пределы.
:)

← →
sniknik © (2009-04-24 02:06) [16]

> Нашел таки :)
даже не написал на нашел? докатились.

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

← →
OtherSie (2009-04-24 02:56) [17]

> например простая накладная - справочник товаров + справочник
> документов, отбрасываем разные отвлекающие поля вроде типа
> накладной, цен товаров для записей, и т.д. оставляем только
> названия товаров и id для связей как у тебя.остается - поле
> с номером накладной, и поле связи по id со справочником
> товаров. в "высоту" прошу заметить, никому в голову не приходит
> для каждой накладной, полей в "ширину" добавлять, если вдруг
> товаров больше пришло. и все. по этим двум полям все находится,
> все записи накладной, по ее номеру, все названия товаров
> из присоединенного по полю связи справочника. и все в "высоту".
> так удобнее.не, конечно и там среди бухгалтеров попадаются
> отщепенцы, придумали такую вещь как шахматка... но и ее
> делают. чаще всего "поворачивая" полученный результат на
> клиенте, делая из "высоты" "ширину". можно и на сервере,
> легко могу сделать на access или mssql но на FB боюсь
> их синтаксис не пройдет, даже не пытаться не стоит (а трудов
> чтобы разбираться задача не стоит. глупая логика).

Что то ты в дебри полез. Было достаточно сказать, что у таблиц могут быть псевдонимы.

> даже не написал на нашел?

Не уверен, что верно понял сказанное. Имелось в виду, что нашел, что у таблиц могут быть алиасы. Хорошая фича.

> данные во всех полях связей обязательны,

Без проблем. Делаем дефолтное значение 0 у таблицы джобов, а нулевому юиду ставим в соответствие что-нибудь типа "не назначено".

← →
AndreyV © (2009-04-24 07:47) [18]

> [17] OtherSie (24.04.09 02:56)
> Что то ты в дебри полез. Было достаточно сказать, что у
> таблиц могут быть псевдонимы.

И это всё, что ты увидел в ответе, хотя об этом в нём не говорилось.

Экселем мыслим.

← →
MsGuns © (2009-04-24 09:15) [19]

>Имелось в виду, что нашел, что у таблиц могут быть алиасы. Хорошая фича.

Как много нам открытий чудных
Готовит просвещенья дух
И опыт, сын ошибок трудных,
И гений, парадоксов друг
:))

← →
Виталий Панасенко (2009-04-24 09:56) [20]

(с) "Очевидное-невероятное"...

← →
Виталий Панасенко (2009-04-24 09:56) [21]

шЮтка, конечно А.С.Пушкин.:-)

← →
ANB (2009-04-24 11:06) [22]

А потом заказчики удивляются, когда профи, которого просят "чуток доделать уже почти готовую" систему, требует денег за написание новой.
Дамс.

← →
sniknik © (2009-04-24 11:08) [23]

> Имелось в виду, что нашел, что у таблиц могут быть алиасы. Хорошая фича.
кто ж знал, что ты не знаешь про псевдонимы, про которые пишут на 15-20 й странице любого учебника по sql. и проблему ты видишь только в этом...
я вот вижу у тебя проблему в нежелании работать со списками, непонимании логики баз. а вовсе не в алиасах.

кстати, у твоего подхода есть минус, кроме того что там полей не напасешься, ну вот представь, что после будет например 200 человек... 200 полей, и 200 объединений таблицы самой с собой, вместо одно... это хороший способ поставить "на колени" любой sql сервер. даже четыре могут тормозить при определенных условиях. (размер таблиц/отсутствие или невозможность использование индексов)
вот запиши объединение в явном виде, с помощью join-ов сразу поймешь что имеется в виду. (join-ы это тоже хорошая фича, про которую ты наверное не знаешь, и рекомендуемая к использованию т.к. она ближе к тому как работает sql сервер, больше способствует пониманию, чем неявные объединения)

← →
ANB (2009-04-24 12:07) [24]

> (join-ы это тоже хорошая фича, про которую ты наверное не
> знаешь, и рекомендуемая к использованию т.к. она ближе к
> тому как работает sql сервер, больше способствует пониманию,
> чем неявные объединения)

Зато с ними тяжелее оптимизить запросы.

← →
OtherSie (2009-04-24 12:15) [25]

> И это всё, что ты увидел в ответе, хотя об этом в нём не
> говорилось.

Я собственно это и говорил - что алисов не увидел - сам нашел.

> кто ж знал, что ты не знаешь про псевдонимы, про которые
> пишут на 15-20 й странице любого учебника по sql.

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

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

Вроде бы никакой крамолы. Во всяком случае, пока...

200, как и 1000 человек, думаю, никак не повлияют на скорость. 200 джобов, думаю, там не будет никогда. Далее, в случае необходимости, будем оптимизировать базу. Пока ограничимся имеющимся запросом.

Всем спасибо за ответы.

← →
sniknik © (2009-04-24 12:35) [26]

> Зато с ними тяжелее оптимизить запросы.
дело привычки. тем более когда понимаешь их логику то оптимизировать уже не приходится, сразу пишешь оптимально. а вот в неявных черт ногу сломит, а иногда и sql ый парсер понимает их по разному.

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

> Далее, в случае необходимости, будем оптимизировать базу.
не получится. далее тебе ее придется переделывать с 0.

> Пока ограничимся имеющимся запросом.
вольному воля.

← →
MsGuns © (2009-04-25 14:57) [27]

Сникника пора судить за растрату бисерного фонда :)

← →
OtherSie (2009-04-25 16:44) [28]

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

← →
OtherSie (2009-04-25 16:47) [29]

Особенно когда эта оптимизация утяжеляет решение в разы...

← →
OtherSie (2009-04-25 16:47) [30]

Не давая никакого практического выигрыша.

> [28] OtherSie (25.04.09 16:44)

Ни хочешь слушать советы - твоё право. Но зачем тогда спрашивал, напрягал людей, заметь - бесплатно?

← →
OtherSie (2009-04-25 17:16) [32]

Удалено модератором

← →
Виталий Панасенко(дом) (2009-04-25 19:14) [33]

Удалено модератором

← →
ANB (2009-04-27 10:08) [34]

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

явными хорошо, если ты уже знаешь оптимальный план.

А вот если ты его подбираешь, то частенько вылезает необходимость поменять порядок обхода таблиц. С явными джойнами надо запрос посильнее править.
Да и букав писать больше.
У явных джойнов мне нравятся 2 вещи :
1) Больше вариантов объединения (правда "лишние" варианты весьма экзотические и фулл оутер я всего раз в жизни применял на практике).
2) Труднее забыть про связки и нарваться на картезиан.

> С явными джойнами надо запрос посильнее править.
> Да и букав писать больше.
скопипастить 40 символов намного труднее чем 10?

> 1) Больше вариантов объединения
?
вообще то от синтаксиса конкретного sql сервера зависит, например когда то в первисиве не было синтаксиса явных объединений, но никаких ограничений на их варианты не было, лефт джойн делался += , райт =+ , полное объединение * (или *= с любой стороны, не помню).

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

> sniknik (27.04.2009 10:25:35) [35]

Что там первисив, в Оракле не было.

А я до сих пор в оракле (+) пишу - оно как-то понятнее и серверу и мне и моим коллегам

← →
ANB (2009-04-27 13:55) [38]

> А я до сих пор в оракле (+) пишу - оно как-то понятнее и
> серверу и мне и моим коллегам

Вот и я о том же.

> скопипастить 40 символов намного труднее чем 10?

Если у меня хинт ordered и я начинаю играть порядком обхода, то при неявном объединении мне надо будет только поменять местами таблицы во фроме (вырезать+вставить). А при явном - переделывать текст запроса.

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

← →
Кщд (2009-04-27 14:53) [39]

>Игорь Шевченко © (27.04.09 12:02) [37]
>А я до сих пор в оракле (+) пишу - оно как-то понятнее и серверу и мне и моим коллегам
так, вообще говоря, (+) не эквивалентен left/right outer join
да и (+)-синтаксис при необходимости full outer join не слишком спасает)

← →
Кщд (2009-04-27 14:55) [40]

>ANB (27.04.09 13:55) [38]
>Если у меня хинт ordered и я начинаю играть порядком обхода, то при >неявном объединении мне надо будет только поменять местами >таблицы во фроме (вырезать+вставить). А при явном - переделывать >текст запроса.
а потом, например, dba врубает plan stability, и вся система идет под откос
хинты - это зло, зло и зло)

Как составить запрос к базе Найти похожие ветки