お酒好きのおしりトラブル対策とは

OracleのSQLの質問です。

TO_CHAR()関数の構文で質問です。
TO_CHAR()関数の構文は、
TO_CHAR(〔データ〕,〔出力形〕)ですが、
この〔データ〕において外部結合を示す、
「(+)」があるかと思いますが、
この時の「(+)」はどういった機能を持っているのでしょうか?
WHERE句の「=」で使用する際の「(+)」は意味が分かりますが、
TO_CHAR()関数で使用する「(+)」の意味が分かりません。

このQ&Aに関連する最新のQ&A

A 回答 (2件)

> WHERE句の「=」で使用する際の「(+)」は意味が分かりますが



同じようなもんですよ。
(+)を付けると、結合するテーブルに一致するデータが無い場合、NULLで補います。
外部結合演算子はWHERE句でしか使わないはずなので・・・
TO_CHAR関数をWHERE句内で使う場合の構文なんでしょうね。
    • good
    • 0
この回答へのお礼

回答ありがとうございます。

TO_CHAR関数に対して外部結合演算子を使うときの構文なんですね。
ありがとうございました!

お礼日時:2004/11/06 13:01

(+)演算子は、カラム名にのみ適用できます。


よって、TO_CHAR(col, fmt)(+) という書き方はできません。

ですので、以下のような書き方になる可能性もあります。
TO_CHAR(tbl.col1(+)||tbl.col2(+), fmt)

この回答への補足

質問に不備があり、申し訳ありません。

私がお聞きしたいのは正に、
TO_CHAR(tbl.col1(+)||tbl.col2(+), fmt)
の形式です。

上記の場合、「(+)」を付けた場合と付けない場合で、
どのように変化するのでしょうか?

補足日時:2004/10/28 13:50
    • good
    • 0

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Q外部結合で取得した項目にNVL関数

次のSQL文があります

------------------------------------
SELECT A.*,NVL(B.KOMOKU,'')
FROM A,B
WHERE A.NO = B.NO(+)
------------------------------------

この場合にBにデータがなかった場合に
NVL(B.KOMOKU,'')
が動かなくてNULLが帰ってきてしまいます。
これをなんとか空白として取得するには
どうすればいいのでしょうか?

Aベストアンサー

>NVL(B.KOMOKU,'')
>が動かなくてNULLが帰ってきてしまいます。

長さ0バイトの文字列('')は、nullと同義です。
なので、

NVL(B.KOMOKU,' ')

ような記述になるんではないですか?

QIOException ってどういうときに起こるのでしょうか?

IOException ってどういうときに起こるのでしょうか?

http://www.atmarkit.co.jp/fjava/rensai2/javaent12/javaent12.html
を見て勉強しています。

  catch ( IOException e) {
    System.out.println( "キーボードが故障しているのかもしれません" );
  }

と書いてあります。
ハード(キーボード)が故障しているのを Java のプログラムのレベル(ソフトウェア)で感知できるというのがよくわかりません。「

NumberFormatException の方はわかるのですが・・・

Aベストアンサー

現実的には、キーボードからの入力でIOExceptionが発生することは、
ほとんどあり得ないと思います。
そもそも、キーボードが故障していたとしても、
IOExceptionは投げられないでしょう。
「キーボードが故障しているのかもしれません」というのは、
その記事の著者が冗談で書いたのだと思います。

ではなぜ、try-catchを書かなくてはいけないのか?
InputStreamやBufferedReaderは、
データ入力を抽象化したものだからです。
実際の入力元はキーボードだったり、ファイルだったり、
ネットワーク接続だったりするわけですけど、
InputStreamは、その入力元の情報を持っていないので、
データを読み取る際は常に
IOExceptionをキャッチするコードを書かなくてはいけません。
たとえ、絶対にIOエラーが発生しないストリームだとしても。

さらに付け加えるなら、
そもそも「標準入力=キーボード」であるとは限りません。
(一般的にはキーボードであることが多いですが。)
Javaでは、
System.setIn(InputStream)
を呼び出して、標準入力を変えてしまうことができますし、
標準入力を指定してプログラムを実行することができるOSもあります。

追伸1:
例外をキャッチしたときは、
スタックトレースをプリントすることをおすすめします。
catch (IOException e) {
e.printStackTrace();
}

追伸2:
そのプログラムでIOExceptionを発生させる最も簡単な方法は、
readLine()を呼び出す前に
標準入力(System.in)を閉じてしまうことです。
System.in.close();

現実的には、キーボードからの入力でIOExceptionが発生することは、
ほとんどあり得ないと思います。
そもそも、キーボードが故障していたとしても、
IOExceptionは投げられないでしょう。
「キーボードが故障しているのかもしれません」というのは、
その記事の著者が冗談で書いたのだと思います。

ではなぜ、try-catchを書かなくてはいけないのか?
InputStreamやBufferedReaderは、
データ入力を抽象化したものだからです。
実際の入力元はキーボードだったり、ファイルだったり、
ネットワーク接...続きを読む

Qselect句副問い合わせ 値の個数が多すぎます

SQL初心者です。

ORACLEで、SELECT句に副問い合わせを付けたところ、ORA-00913:値の個数が多すぎますとエラーになってしまいます。
解決法をご教授願います。

同一テーブルの同一項目を複数項目として取得したいのです。

SELECT
(SELECT
B.DDD
,B.EEE
FROM A_MST A
,B_MST B
WHERE A.AAA = B.BBB
AND A.BBB = CMST.CCC),
(SELECT
B.DDD
,B.EEE
FROM A_MST A
,B_MST B
WHERE A.AAA = B.BBB
AND A.BBB = CMST.FFF)
FROM C_MST CMST
WHERE
CMST.A_RYAKU = '123'

Aベストアンサー

WITH AB AS (
SELECT B.DDD AS DDD
,B.EEE AS EEE
,A.BBB AS BBB
FROM A_MST A
,B_MST B
WHERE A.AAA = B.BBB
)
SELECT (SELECT A.DDD FROM AB A WHERE A.BBB = CMST.CCC) AS DDD_CCC
,(SELECT A.EEE FROM AB A WHERE A.BBB = CMST.CCC) AS EEE_CCC
,(SELECT A.DDD FROM AB A WHERE A.BBB = CMST.FFF) AS DDD_FFF
,(SELECT A.EEE FROM AB A WHERE A.BBB = CMST.FFF) AS EEE_FFF
FROM C_MST CMST
WHERE CMST.A_RYAKU = '123'

QHTMLフォームのSELECTの幅を一定にするためには?

HTMLフォームのSELECTの幅を一定にするためにはどのようにすれば
いいのでしょうか?

CSS等で設定できるとありがたいのですが、やり方がわかりません。

Aベストアンサー

<select style="width: 200px">

Q実行計画の「COST」と「BYTE」について教えていただきたいです。

実行計画の「COST」と「BYTE」について教えていただきたいです。

書籍には
COST・・・・CBOによって見積もられた操作コスト。
BYTE・・・・アクセスされるバイト数のCBOのアプローチによる見積もり。
と書かれていますが、いまいちピンときません。


私は、
COSTは、検索するテーブルのデータ量が多いほうがコスト値が大きくなる。
BYTEは、検索条件に合致して取得できるデータが多いほうがバイト値が大きくなる。
と思っているのですが、正しいでしょうか?

Aベストアンサー

このあたりを参考にしてください。
COSTはデータ量だけではなく、その表やViewのアクセスに要する時間やSortや結合が必要なら、そのために必要なCPU時間等も考慮されています。
表があるHDDのアクセス速度なんかも考慮されているし、表のエクステントが複数になっているかとかも考慮されています。
書籍はわかりにくいかもしれませんが、嘘は少ないと思います。著者が思い違いをしてないとは言い切れませんが。

参考URL:http://otn.oracle.co.jp/forum/message.jspa?messageID=35016743


人気Q&Aランキング

おすすめ情報