Вопрос по синтасису coalesce в оракле

← →
Rule © (2005-07-26 16:41) [0]

подскажите пожалуйста как сделать вот такой запрос
select coalesce (field1,0) from table1

Синтаксис Оракла требует чтоб второй параметр, в моем случае "0" тоже был полем ...
как обойти

вариант if then не подходит так как в этом случае field1 надо писать два раза, а у меня єто довольно большой подзапрос ....
подскажите пожалуйста ...

← →
Sergey13 © (2005-07-26 16:46) [1]

А тебе случаем не NVL нужен?

← →
Fay © (2005-07-26 16:48) [2]

2 Rule © (26.07.05 16:41)
> Синтаксис Оракла требует чтоб второй параметр, в моем
>случае "0" тоже был полем ...
Чушь.

← →
Rule © (2005-07-26 16:50) [3]

Fay © (26.07.05 16:48) [2]
почему єто чушь ORACLE8 и по английцки я читать умею

← →
Johnmen © (2005-07-26 16:51) [4]

>Rule © (26.07.05 16:50) [3]

Я тоже не верю, что Оракул отклонился от стандарта.
Ошибку и текст запроса в студию !

← →
Rule © (2005-07-26 16:52) [5]

Sergey13 © (26.07.05 16:46) [1]

Точно, Сергей, большое спасибо ...

← →
Sergey13 © (2005-07-26 16:52) [6]

Ты чего хочешь то в результате?

← →
Rule © (2005-07-26 16:52) [7]

Johnmen © (26.07.05 16:51) [4]
щас секундочку

← →
Rule © (2005-07-26 16:53) [8]

вот запрос

select a.date_trn,
a.time_trn,
b.name_services,
a.sum_for_what,
b.unit_of_measurements,
a.price_terminal,
a.price_terminal*a.sum_for_what,
(select c.VAL from V_INT_DTARIF_ITEMS c,
V_INT_DTARIF d,
V_CLIENT_DTARIF e
where c.dtarif=d.id
and d.id=e.int_dtarif
and e.id_client=a.id_client
and c.id_service=a.id_services_for_what)||
(case when (select c.TYPE_VAL from V_INT_DTARIF_ITEMS c,
V_INT_DTARIF d,
V_CLIENT_DTARIF e
where c.dtarif=d.id
and d.id=e.int_dtarif
and e.id_client=a.id_client
and c.id_service=a.id_services_for_what)
= "C" then " коп."
else " %"
end) as discount,
a.BASE_DELTA_SUM,
a.SUM_THAN_REAL,
a.SUM_THAN

from V_ECFIL139 a, V_ECFIL001 b
where a.id_services_for_what=b.id_services
and a.reason_change=11

← →
Rule © (2005-07-26 16:54) [9]

вот то страшное составное поле первая часть пишет количество скидки а вторая тип скидки, копейки или проценты вот если скидки под клиента нет, то тип скидки выдет проценты а количество должно быть 0, тоесть
(select c.VAL from V_INT_DTARIF_ITEMS c,
V_INT_DTARIF d,
V_CLIENT_DTARIF e
where c.dtarif=d.id
and d.id=e.int_dtarif
and e.id_client=a.id_client
and c.id_service=a.id_services_for_what)

вот эту часть нада сделать NVL

← →
Rule © (2005-07-26 16:55) [10]

если писать вот так вот
select a.date_trn,
a.time_trn,
b.name_services,
a.sum_for_what,
b.unit_of_measurements,
a.price_terminal,
a.price_terminal*a.sum_for_what,
coalesce((select c.VAL from V_INT_DTARIF_ITEMS c,
V_INT_DTARIF d,
V_CLIENT_DTARIF e
where c.dtarif=d.id
and d.id=e.int_dtarif
and e.id_client=a.id_client
and c.id_service=a.id_services_for_what),"0")||
(case when (select c.TYPE_VAL from V_INT_DTARIF_ITEMS c,
V_INT_DTARIF d,
V_CLIENT_DTARIF e
where c.dtarif=d.id
and d.id=e.int_dtarif
and e.id_client=a.id_client
and c.id_service=a.id_services_for_what)
= "C" then " коп."
else " %"
end) as discount,
a.BASE_DELTA_SUM,
a.SUM_THAN_REAL,
a.SUM_THAN

from V_ECFIL139 a, V_ECFIL001 b
where a.id_services_for_what=b.id_services
and a.reason_change=11

← →
Rule © (2005-07-26 16:57) [11]

то пишет
ORA-00904: Invalid column name

← →
Rule © (2005-07-26 16:59) [12]

а только что написал вместо coalesce - NVL, то заработало ...именно это мне и надо было

← →
Rule © (2005-07-26 17:00) [13]

Rule © (26.07.05 16:57) [11]
а вот если вместо нуля написать какоелибо поле, то он когда пустое значение подставляет это поле, как и полагается ... тоесть он требует поле в качестве параметров, а не значения, а вот в Фаерберде можно и значение написать и потребность в NVL как бы отпадает

← →
Johnmen © (2005-07-26 17:03) [14]

>Rule © (26.07.05 17:00) [13]

А если вместо "0" написать 0 ?

← →
Rule © (2005-07-26 17:04) [15]

Johnmen © (26.07.05 17:03) [14]
тоже самое, сразу пробовал

← →
Johnmen © (2005-07-26 17:05) [16]

>Rule © (26.07.05 17:04) [15]

Да... Занятно... Отступили-таки...:)

← →
evvcom © (2005-07-26 17:05) [17]

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

← →
Reindeer Moss Eater © (2005-07-26 17:08) [18]

И в оракле можно указать как поле так и значение.
Decode(что-то, опция_1, выражение_1, опция_2, выражение_2, ......,опция_n,выражение_n,выражение_во_всех_прочих_случаях)

← →
Rule © (2005-07-26 17:08) [19]

evvcom © (26.07.05 17:05) [17]
другого выхода тут нет ...
и особых затрат времени нет, на поной базе выполняется за очень короткое время, моргнуть не успеешь, тем более запрос выполняется раз в месяц для составления отчета, поэтому помоему никаких тут глюков не вижу ..., таблицы то маленькие, те которые в поля встраиваю

← →
Rule © (2005-07-26 17:09) [20]

Reindeer Moss Eater © (26.07.05 17:08) [18]
немного не то, я ж не буду перечислять все возможные варианты процентных и абсолютных скидок ... смотрел уже в эту сторону

← →
evvcom © (2005-07-26 17:09) [21]

> Да... Занятно... Отступили-таки...:)

Да нифига не отступили. Нормально оракловый coalesce принимает хоть поле, хоть константу. Проверял только что на 9.2.0.6. И в документации написано "expression". Просто "афтар" чего-то напутал.

← →
Johnmen © (2005-07-26 17:10) [22]

>evvcom © (26.07.05 17:05) [17]

А что, они должны в данном случае по разу выполнится ?????????
Тогда это бред какой-то......

← →
Johnmen © (2005-07-26 17:11) [23]

>evvcom © (26.07.05 17:09) [21]

Кому же верить, если хочется всем ?

← →
Rule © (2005-07-26 17:11) [24]

Johnmen © (26.07.05 17:10) [22]
я так понял evvcom © имел ввиду внешнее объединение вместо подзапросов ...

← →
Rule © (2005-07-26 17:12) [25]

evvcom © (26.07.05 17:09) [21]
вот щас возьму запросик попроще ... и скажу точно

← →
evvcom © (2005-07-26 17:12) [26]

> другого выхода тут нет ...

Выход есть всегда. См. http://delphimaster.net/view/3-1122378297/, там запрос аналогичен твоему, а в [8] я эти "внутренности" вынес наружу.

← →
Johnmen © (2005-07-26 17:14) [27]

>Rule © (26.07.05 17:11) [24]

Если он это имел в виду, то не учел, что не всегда можно получить желаемое, просто заменив вложенные кореллирующие на соединение. И наоборот.

← →
Rule © (2005-07-26 17:14) [28]

таблица состоит из одного поля сделал запрос
select coalesce(CARD_NUMBER,"0") from V_BL
тот же результат так что наверное в Oracle8 под другома нежели в 9

← →
Rule © (2005-07-26 17:15) [29]

Johnmen © (26.07.05 17:14) [27]
вот и я так попытался объяснить токо не так хорошо получилось ...

← →
Rule © (2005-07-26 17:16) [30]

evvcom © (26.07.05 17:12) [26]
я не уверен что так будет быстрее,

я лично уверен, что так объединять стоит если вот те таблицы с которыми клеишь большие, а если они по 3-20 записей, то оптимальнее использовать именно подзапросы (проверено на практике), и ИМХО конечно, но вот такой с подзапросами запрос более читабельный нежели с объединениями ...

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

← →
evvcom © (2005-07-26 17:17) [31]

> А что, они должны в данном случае по разу выполнится ?????????

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

> Johnmen © (26.07.05 17:11) [23]
> >evvcom © (26.07.05 17:09) [21]
>
> Кому же верить, если хочется всем ?

В данном случае [18] и [21]

← →
Rule © (2005-07-26 17:19) [32]

evvcom © (26.07.05 17:12) [26]

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

← →
Rule © (2005-07-26 17:20) [33]

evvcom © (26.07.05 17:17) [31]
В данном случае [18] и [21]

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

← →
evvcom © (2005-07-26 17:22) [34]

> поэтому я считаю, что объединять стоит если объединямые
> таблицы большие, именно тогда будет выйгрышь в противном
> случае все только усложняется

Выигрыш будет в любом случае, если оптимизатор не разрулит сам. Вопрос только в том, будет ли он заметен. А насчет усложнения все зависит от того, как ты привык думать. Мне нагляднее обозревать INNER JOIN ... ON, нежели потом в where выискивать по каким же полям там эти таблицы/подзапросы вяжутся? Имхо.

← →
Johnmen © (2005-07-26 17:22) [35]

>Rule © (26.07.05 17:19) [32]

Немного режет слух... Не надо называть "соединение" (JOIN) "объединением" (UNION).

← →
Rule © (2005-07-26 17:24) [36]

Johnmen © (26.07.05 17:22) [35]
сори :-), естественно имел ввиду соединение :-), тоесть джоин

← →
Rule © (2005-07-26 17:25) [37]

evvcom © (26.07.05 17:22) [34]
я ж говорю что в данном случае
INNER JOIN не подходить надо LEFT JOIN а там уже мудрить и получается чем больше таблиц я слева прикрепляю, тем больше они перемнжаются, и тогда использование тех же агрегатов становится нереальным ... помоему геморой

← →
Johnmen © (2005-07-26 17:28) [38]

>evvcom ©

пост [27]

← →
evvcom © (2005-07-26 17:29) [39]

> Rule © (26.07.05 17:20) [33]

Ладно, не буду про 8 говорить, а в 9 проверил, все работает.

← →
Rule © (2005-07-26 17:30) [40]

evvcom © (26.07.05 17:29) [39]
на это и спишем :-), восьмой не может а девятый может :-)

← →
ANB © (2005-07-26 17:37) [41]

А как в 8 join то запихать ? У меня не жрет . . .

← →
Fay © (2005-07-26 17:39) [42]

2 ANB © (26.07.05 17:37) [41]
Никак. JOIN-ы появились в девятке

← →
Johnmen © (2005-07-26 17:44) [43]

Явные джоины, т.е. слово "JOIN"

← →
evvcom © (2005-07-26 17:52) [44]

> Johnmen © (26.07.05 17:28) [38]
> >evvcom ©
>
> пост [27]

Да, почитал я этот пост. Может быть, но думаю, что нет. Если бы реальный запрос был, тогда можно было бы попробовать поспорить. А так, слова, слова, слова... :)

← →
Rule © (2005-07-26 18:02) [45]

Fay © (26.07.05 17:39) [42]
что серьезно ? ... а как же без них обходились то ?

← →
Rule © (2005-07-26 18:03) [46]

Johnmen © (26.07.05 17:44) [43]
а неявные - это WHERE или что-то ещё ?

← →
Rule © (2005-07-26 18:03) [47]

evvcom © (26.07.05 17:52) [44]
придумать несолжно ... постараюсь до завтра придумать, если не забуду ...

← →
Johnmen © (2005-07-26 18:05) [48]

>Rule © (26.07.05 18:03) [46]

Да.

← →
pasha_golub © (2005-07-26 19:26) [49]

Сорри за офтоп.

Я вот (только не плюйтесь) до недавнего времени свято верил, что JOIN"ы это происки капиталистов. Что всегда можно перепесать запрос с соединением как запрос без соединения.

Прошло немало времени. Но мысль таки в голове осталась. Прав ли я? И если не прав, то можно ли привести пример такого запроса. Спасибо

← →
Fay © (2005-07-26 20:23) [50]

2 pasha_golub © (26.07.05 19:26) [49]
Сервер какой?

← →
pasha_golub © (2005-07-26 21:00) [51]

Fay © (26.07.05 20:23) [50]
Ы-ы-ы... :0)

Ну, допустим Oracle. Раз у него до 9 версии не было этих самых JOIN"ов.

А вообще-то, хотелось бы пример с использованием ANSI SQL.

← →
evvcom © (2005-07-26 22:32) [52]

> Ну, допустим Oracle. Раз у него до 9 версии не было этих
> самых JOIN"ов.

Не было в синтаксисе конструкции JOIN, но само соединение было:
from a, b where a.id=b.id - это аналог INNER JOIN
where a.id=b.id(+) - это вроде LEFT JOIN, но с плюсами я видел, но толком никогда сам не использовал, поэтому этот синтаксис и смысл (LEFT или RIGHT в данном случае) не помню. Поэтому не пинать.
Плюсы с обеих сторон - это FULL JOIN. Но построить сложную логику типа "inner join a ... left join b ... right join с ... full join d ..." в where у меня в свое время не получилось и "старики оракла" тоже только плечами пожали. Оракл ругался на использование этих плюсов в нескольких строках.
Кому-то может и не нравятся JOIN-ы, но мне они кажутся намного информативнее, и код с ними наиболее наглядным и читабельным.

> Rule © (26.07.05 18:03) [47]
> evvcom © (26.07.05 17:52) [44]
> придумать несолжно ...

Гораздо сложнее, чем ты думаешь. Если ты не знаешь, как решить задачу неизвестным тебе способом, это не значит, что она им не решается. :) Но попробуй.

← →
pasha_golub © (2005-07-27 13:45) [53]

← →
ANB © (2005-07-27 13:49) [54]

> Fay © (26.07.05 17:39) [42]
- и в 9 не жрет . . .

← →
evvcom © (2005-07-27 14:52) [55]

> - и в 9 не жрет . . .

Еще как жрет! Уж это точно.

← →
ANB © (2005-07-27 14:56) [56]

> evvcom © (27.07.05 14:52) [55]
А, пусть жрет. Мне с плюсиками все равно больше нравится

> Мне с плюсиками все равно больше нравится

Хозяин - барин. А если
> построить сложную логику типа "inner join a ... left join
> b ... right join с ... full join d ..." в where у меня в
> свое время не получилось и "старики оракла" тоже только
> плечами пожали. Оракл ругался на использование этих плюсов
> в нескольких строках.
А?

2 pasha_golub © (26.07.05 21:00) [51]

C Oracle не интересно 8). Он один справится с
select
T1.*
from Table1 T1 left join Table2 T2 on T1.ID = T2.ID
where T2.ID is null
без join.

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

Кстати, в блоках вообще все легко через курсоры разруливается.

Кому-то может и не нравятся JOIN-ы, но мне они кажутся намного информативнее, и код с ними наиболее наглядным и читабельным.

Это наверное вопрос привычки. Я всегда обходился условиями в where и JOIN мне был очень интуитивно не понятен )
Да и нужен он был только в случае внешнего объединения LEFT JOIN - но я всегда старался проектировать так что бы этой надобности не было.
В последнем проекте все обошлось полностью без LEFT JOIN - только =

by © (27.07.05 18:00) [63]
Во-во, абсолютно согласен. JOIN"ы начал воспринимать исключительно из-за необходимости. Хотя не считаю их информативными, если честно...

Что значит "переделывает в джойны"?

Получив текст запроса ... FieldA = FieldB(+) ...
движок сам себе его перековеркивает в текст запроса содержащего слово "Join"?

:)))

Reindeer Moss Eater © (28.07.05 15:39) [66]

ну оптимизатор запроса все выстраивает в джоины как бы ты не писал ...я не говорю про плюсики я говорю про условия, оптимизатор все условия переделывает в джоины (условия по связям таблиц)

Ты хочешь сказать, что Ларри Эллисон придумал специфичный для Оракла синтаксис открытых соединений для того, что бы его оптимизатор занимался переводом самому себе, со своего родного языка на язык стандарта?

Как если бы я в разговоре с тобой переводил сам себе твои фразы на русском сначала на латынь, затем обдумывал ответ на латыни, переводил бы его на русский и отвечал тебе.

2 Reindeer Moss Eater © (28.07.05 16:18) [68]

Не нужно юродствовать. Вы же не думаете, что движок Oracle "думает" на SQL?!

Зашибись.
А на чем он "думает", если он не "думает" на SQL?

На специфичном для Оракла синтаксисе серверу поручили выполнить открытое соединение таблиц:

... where FieldA = FieldB(+)

Что меняется для сервера, если он преобразует этот синтаксис к стандартному?

Ему будет более "понятно", что одна таблица соединяется с другой с помощью открытого соединения?
Чушь.
Ему это и так было понятно из инструкции на его родном языке.

Reindeer Moss Eater © (28.07.05 18:06) [71]
твоя ошибка в том что ты преподнсишь все так, как будто он к текстовому виду преобразует, а он не преобразует, и от такого как позволяет синтаксис писать толи джоин толи равно с плюсиком толи фром несолько таблиц вхере связ по ключам, от этого внутреннее объединении движком не меняется, все равно движок объединяет таблицы для выполнения запроса посредством джоинов ... но это не значит что он для себя это слово пишет, он просто объединяет

Твоя ошибка в том, что ты забыл с чего мы начали.

А начали мы с того, что якобы сервер все запросы приводит к джойнам.

>вопрос то в том, что все равно потом движок это все в джоины переделывает

А то, что в результате получается джойн (объединение таблиц) - америку не надо было открывать.

Или ты хотел нам поведать страшную тайну, что сервер получив команду объединить таблицы, начинает объединять таблицы?

> ANB ©

Можно то можно, только вспомни ту же математику. В чем легче разобраться, что нагляднее: многоэтажная дробь или все же малоэтажная? Так или иначе, прежде, чем работать с дробью, мы ее упрощаем, т.е. приводим к одноэтажной простой дроби, ибо проще с такой работать.
Ну а насчет наглядности, мое имхо остается с явными джойнами. В join сразу видно, по каким полям вяжутся наборы, а в from и where надо еще эти связи искать. Согласен, дело вкуса.

Зато с join поди ищи список таблиц по всему запросу.
А в синтаксисе Оракла они всегда после From и нигде больше.

2 Reindeer Moss Eater © (29.07.05 8:47) [76]
Дык... с этого и надо было начинать! 8)
Всем, видимо, по-разному, а мне вот не очень удобно высматривать в здоровом WHERE условия соединения. При чтении глазками, естествено.
К "join-скому" запросу проще приделывать фильтры (в общем случае) - просто дописываем WHERE тра-ля-ля. C "плюсиками" надо выдирать это самое WHERE и т.д.

А если по-хорошему, то вопросы религии у нас обсуждаются в Потрепаце 8).

> Зато с join поди ищи список таблиц по всему запросу.
> А в синтаксисе Оракла они всегда после From и нигде больше.

Не по всему, а именно после from, но с join и тут же условие связи. Каждая новая таблица с новой строки, ничего не ищется.
Всё, это последний мой пост на эту тему.

Синтаксис с джойнами допускает несколько таблиц во FROM.
Итого: часть условий объединения будет во WHERE, а часть после JOIN.
То, что вы все объединяемые таблицы пишете с новой строки ничего не меняет.
Обсуждается - то синтаксис, а не вы лично.

2 evvcom © (29.07.05 9:08) [78]
>> Всё, это последний мой пост на эту тему.
Поддерживаю. Случай не тяжёлый, но неизлечимый 8).

Вопрос по синтасису coalesce в оракле Найти похожие ветки