★★ Oracle,DB2,Teradataって　★★

これまで、題目の３つのデータベースの開発をしてきましたが、
設計の時点で物理的なデータ配置がどうなっているのか
分からず、チューニングに苦労しまくりでした。

いったい、この３つの内部処理っていったいどうなってるの？！！

Ｏｒａｃｌｅなんて参考書読めばいーじゃん！>1
内部構造なんてわかりきってるおもうけどね。

Ｔｅｒａはあれだね。ミニシルパックコワイね。
あとﾊﾞｰｼﾞｮﾝあげたら文字コードでもめたことが・・。
でもupsertとかfastexportって強力だよなあ。

DB2は知らん。

Sybaseも使え。

Oracle: 確か一個のテーブルが一塊として、ディスクに置かれると読んだ
事があるんですが、それがいったいなぜ、大量のユーザー処理に向かないの
でしょうか？　それからINDEXって、どんな役割なんでしょうか？
Teradata:ハッシュでディスク上にばら撒くと言う事で、かなりデータ処理
は高速だと知っています。なんかOracleよりずっとメリットがあるもの
じゃないでしょうか？どうしてマイナーなのかな。
DB2：最近Teradataを、真似た機能を載せたとか聞きましたけど、
あまり知りません。

Oracleは一個の表の中の論理的な単位（ＥＸＴＥＮＴ）毎に
ファイルに分けられるよ。あんまりやる人はいないと思うけど・・。
やりたきゃパーティションオプションもあるし。
設定は考えられることはたいていできるんだけど、それゆえに
きちんとやろうとすると管理負荷が大。
ただしパフォーマンスを追いこまなきゃならないような
ハードウェア要件で無い限りデフォルトでもそこそこは動く。
それよりはＳＱＬ文の解析パスをきちんと調査してアプリを組むほうが
ずっと大事。

Teradataは大量一括処理が高速らしいですね。
ユーティリティが完備してるので。ただＮＣＲ製品だしねえ。
でもテラ技術者なんてほとんどいないだろうし、
ＰＪにＮＣＲの技術者をまぜないといけないこととか
性能とは違った部分の制約が多いです。

ＤＢ２は投げ売りなので、Ｏｒａｃｌｅと比べると値段が魅力的です。
ＴＣＯを考えるとこれからＤＢ２は伸びるかもしれないですね。

Oracleがこれだけ管理者の負荷が高いのに対して、
Teradataなんてウチ（ソフトハウス）のメンバーだけで
ちゃんと動いたよ。必要な機能についてマニュアル読めば
大体できてしまう。俺も最初先入観で毛嫌いしていたが、
実際は、いいもんだと思う。

DB2はややこしかった。ムヅイ、、、。

あげ

Teradataの資格もってる人っていてる？

>>8
私はあなたが誰かを知っている、、、。マジで。

>>9
定例以外にもたまには顔を見せに来てくださいね。(笑

age

MS Accessってどうよ？

ＤＢあげあげ

>>12
MS-ACCESS はローカル処理では最速。共有環境に難あり。
Teradataはインデックスを使うよう明示的に指定しないと使ってくれなかった。
なめる処理も速いとは思えなかったが。（記憶あいまい）
Oracleでパーティション機能を使うのが現状ではベストかも。
でも、あらかじめパーティションを作っておく必要があるのがうざい。
絶対自動化できるはず。(->Oracle社)

>>14
partision作るの自動化なんてできっこないって。
無理やりやったって意味ないと思うなあ。
データファイルのHDへの割り当てとか、
IOチャネルの速度とか、そこまで
考えて設定すべきもんなのだから。
そこまで考えて自動化できたら、
それはAIだよ。

>>15
CREATE TABLE 文で広範囲なパーティションをすべて指定しておき
各パーティションに初めてデータがINSERTされた時点で、実際の
EXTENTを作成するって感じでどう？
もちろん実行計画を立てるときは、データが存在するパーティション
だけを対象としてほしい。

>>16
そのレベルならわからんでもない。
でも、それって、ガリガリに物理チューンしようって
いうよりも、手抜いて楽しよう、ってスタンスだよね。
開発機でよくあるスタンスだ。
それなら、
initial extent を最小の1ブロック（＝２Kとか）
にしておいてnext extentをそれなりの大きさに
しとけば？
データ０でも最初のエクステントはなめちゃうけど、
１ブロックだから勘弁してあげるということで。

>>15 ひつこくてゴメンね。
以前、テスト的に１年半分のデータを一日単位で５００くらいの
パーティションに分けた時、動きがちょっと鈍かったんだよね。
実行計画を立てるところで待たされる感じ。
初期パラメータも（どれだったか）増やさないといけなかったし。

不要なパーティションは作りたくないが、目を離した隙に全部
MAXVALUEのパーティションに集まっているのもいや。

>>4
Teradata:ハッシュでディスク上にばら撒くと言う事で、かなりデータ処理
は高速だと知っています。なんかOracleよりずっとメリットがあるもの
じゃないでしょうか？どうしてマイナーなのかな。

Teradataは、内部のハードウェア構造を良く理解してないと、
本当の性能を出すことは難しいよ。データが少ない場合はあま
り関係ないけど。オレも最初はＮＣＲのインド人エンジニアに
いろいろ教えてもらってた。
Oracleよりマイナーな理由は明らかであって、書き込み性能（と
いうよりはトランザクション処理性能）は全然悪い、ほとんど
ＤＷＨ専用にしか使えない、ＮＣＲのマーケティング力のなさ、
かな。

>>18 こっちもしつこいかもしんないけど、
つきあっちゃうね。

パーティションを５００も作るのは、
使い方としてそもそも間違いではなかろうか。

ここいらのORACLE8機能を
俺もそんなに使いこなしているわけでは
ないので、大嘘があるかもしれんが、
俺の理解としては、
１年半なら月単位でせいぜい１８個が
いいせんじゃないかな。日単位検索するなら、
その中でINDEXを設定して高速化を図るもんだ
と思ってました。

というのは、パラレルオプションなしで
パーティショニングする場合は、
領域管理を楽にする意味しかないと思うし、
高速化の観点ならパラレルオプションとの併用
を考えなきゃだめで、パラレルは、
サーバCPU数とか、SCSIチャネル数とか
ここいらの個数と同じ数の並列度しか動かんので、
この意味で１桁か２桁の下のほうでしょう？
３桁のパーティション数はないんじゃない？

ORACLEさんも、そんな使い方想定
していないんじゃないのかな？

ってゆうか、ペンタゴン破壊されたぞ！！！

大変だぞー！ペンタゴン潰れたぞーすんごいぞー！！！！！！！！！！！！！！！！！！！！！！！！！

なんか、ゆえよ！ペンタゴン潰れたんだぞ！あと世界貿易センターも！

>>15
本番データは１日分が１００MB以上あるので、INDEX経由で日指定の
集計をするとえらく時間がかかります。
INDEXは、総データ件数にかかわらず該当件数が数件なら超速いですが、
該当件数が数百万件になると、とてもとても遅いのです。
FULLヒントでなめる必要がありますが、日指定でなめるには日単位の
パーティションが必要だと思ったのですよ。

ほとんどINDEX代わりに使っているので、複数のパーティションを
パラレル処理するのとは目的がちょっと違います。

確かにORACLEの想定外だと思うけど、想定してほしいわけですよ。
EXTENTが1,000以上OKなら、パーティションも1,000以上作れても
いいんじゃないか。ってね。

DB2って使われてないの？

>>19
やはり、得不得意があるんですね。言われたように、全体的に見れば
Teraは検索向きで更新トランザクションは弱いです。
ただし、構造を意識しなくてもある程度の速度が出るのは評価できる
のではないでしょうか。逆にそれ以上の速度出すのは難しい側面も
もちます。とりあえずの器でしょうか（それにしちゃ高いかな）。
そもそも、米国で日本のように、Tera単独では、ほとんど使われて
いませんし。メインフレームへチャネル接続でDB（diskマシン）と
して利用されてますね（またインド人の方に会ったら聞いてみてく
ださい）。単独では、大容量データの保存向きですが、
大容量データ処理には向いていません。大容量からの少量抽出向き
マシンと思ってください。
向き不向きってことです

teraの並列処理のロジック理解されていらっしゃる方います？
ハッシュでディスク上にばら撒くだけで早くなる？
ぺんてぃあむを並べただけの機械であれだけスピードが出るのは
不思議なのですけど．．．

>>24
そんなバカデカイデータをなんでＤＢ化するのか不明なんだけど．．
メリットでもあるのですか？

集計結果だけをＤＢ化するのが常套手段ではないの？

>>28
規模が大きければこれぐらいのサイズのDBなんて
幾らでも必要になってくるでしょ！

>>29
うん、だけどその場合それなりのマシンを用意するよね。

24さんの場合、完全にミスマッチに思えるのね。
で、明細をそのままＤＢ化する必要性も感じないのよ。

>>出張32さん こんにちは
100MB/日は明細ではなく集約データです。
商品別とか日別とか、いろいろな角度から集計しようとすると
ある程度の細かさで集計する必要があったようです。

400日持っても40GBなので、テラバイトデータベースを標榜している
オラクルにとっては決して大きくはないと思います。
ハードはこれ以上無いという機種ですが、FULLでなめるのは速くても
インデックスを使った検索はちょっと苦手のようです。

そうなんだ！
それにしては変ですね。
大手の百貨店の顧客管理システムが現実にオラクルで動いてますよ。
因みに、管理対象データ件数は４億件(年間２億)なんです。

索引振りまくってるよ。

あ！
もしかして、複数テーブルを関連付ける時にフル結合多様してないですか？
それって致命的に低速(1/100-1000)になるよ。
結合式はフルじゃなくて片側結合にして下さいね。

× a = b
○ a = b(+)

# 後はチューニング次第だと思うよ。
# テーブル作成時の設定値も重要と思います。(デフォルトじゃないよね)
# 専門家じゃないから対した事言えなくてゴメン！

>>33
そんなの、チョー当たり前のことじゃん
くだらないレス

>>24
そもそも、マシンスペックは、どう？
経験では（ORACLEは少ないが）、結局、行き着くところ
メモリとCPUってところになっちゃうんだけど。
ORACLE社の奴なんて、いつもそのセリフだったぜ。

>>33
ヘ？

>結合式はフルじゃなくて片側結合にして下さいね。

フル結合と片側結合の定義は何？

>× a = b
>○ a = b(+)

外部結合を使えと？
何言ってんの？

>>34
>そんなの、チョー当たり前のことじゃん
ｻﾑｯ｡ﾌﾞﾙﾌﾞﾙ｡

>>35
意味が判らないようですね。
今回は24番さんへのアドバイスですので説明は省略させて頂きますね。

# 気になるようなら専門書でもお読みくださいませ。

>>37
そんな専門書を読まなきゃ分からないような言葉なの？
だったら、なおさらアドバイスになってないんじゃないの？

んで、外部結合の件はどうなのよ。

ってか、SQL92的な（あるいは少なくともSQL86の）言葉で語ってくれよん。
英語でもいいからさ。

ってか、インデックスはフツー『張る』モノなんだけど。
どこ（どのＤＢ）の方言？

>>38
外部結合や内部結合は実装手段を意味するので関係御座いません。
頓珍漢な質問はお止めくだされ。

>>39
オラクルでお考え下され。

>>40
検索手法(結合手法)を言ってるだけでおます。

>>35（俺）
>フル結合と片側結合の定義は何？

>>37
>意味が判らないようですね。
>今回は24番さんへのアドバイスですので説明は省略させて頂きますね。

>>38（俺）
>そんな専門書を読まなきゃ分からないような言葉なの？

>>41
>外部結合や内部結合は実装手段を意味するので関係御座いません。

フル結合と片側結合の定義を質問しているのであって、外部結合や内部結合
について質問しているのではありません。

>>41
>オラクルでお考え下され。
俺Oracle結構詳しいんだけど、そんな言葉初めて聞いた。
だから質問してるのに。

>>>40
>検索手法(結合手法)を言ってるだけでおます。

インデックスを「振る」という流派ははじめて見たから、ある特定ベンダー
の特定RDBMSしか知らないんじゃないかと思ったんだよ。
ってか、ずれてるよ、アンタ。

>>24
DWH使えば？

>>42
> んで、外部結合の件はどうなのよ。
しっかり問題にしてるじゃん！（笑

>>43
だから、自分で専門書買って調べろって言ってるじゃん！（笑

> インデックスを「振る」という流派ははじめて見たから

そうか？
振るでも張るでもどっちでも良いぞ！
君は、テーブルをファイルと言われたら理解出来ない君なんだろうね♪

>>45
>しっかり問題にしてるじゃん！（笑

問題が二つあることに気づいていないらしい。

ごまかさないで質問に答えたほうがいいんじゃない？
あなたの技術力が試されてるんだよ。

>だから、自分で専門書買って調べろって言ってるじゃん！（笑

なんだ、結局説明できないんだ。
自分で説明できないんだったら、マニュアルや書籍へのポインタやURLでも
いいので、示してください。

それも出来ないようだったら、今後、説明も出来ないような言葉を使って
適当なアドバイスなどしないこと。
アドバイスされる側も、読む人間も迷惑なので。

>振るでも張るでもどっちでも良いぞ！

という認識なんだ。

>君は、テーブルをファイルと言われたら理解出来ない君なんだろうね♪

出来るけど、自分から使う場合は時と場合を選ぶね。

あー、それから、俺はデータベース関連のかなりの専門書ももってるし、
Oracleもプラチナホルダーだから、いいかげんなことは言わないほうがいいよ（藁

>>46,47
君達素敵だね♪
こんなにも素直に反応してくれると楽しいよ。
必死に此方の意図通り踊ってくれる姿を見るに、
「突っ込み個所をひたすら探す姿が浮かび上がって微笑ましいね。」

はっきり言うと、君達は「外部結合演算子」を問題にしたいらしい。
そう、構文で言うと確かに片側結合を表現する為にオラクル規定の演算子が使われているよね。
で、私が「外部結合演算子」と言うコトバを使わずフル結合、片側結合って表現したのを
受けて違和感を感じ突っ込んだわけだ！（笑

ところが、突っ込みには残念なことに「演算子」と言う言葉抜け落ちていた。
そこで私は似通った言葉で全く概念の異なる実装方向へと意図的に誘導し楽しんだってわけね♪

で、何が言いたいのかと言うと、
私にしても君達にしても話題に必要な個所の情報伝達は正しく行えているってことが言いたいのだよ。
つまり、「外部結合演算子」なるものも所詮は造語であってその意味するものを正確に伝える為には
解説(規定されたもの)する必要があるんだわ。(笑
で、君達は「片側結合」って言葉を聞いて必死になって、解説(規定されたもの)を私に要求したのよね。
なるほど、確かに一見すると当然の要求であるように思える。
されど、よくよく考えてみるとその可笑しさに気付く。
そう、解説(規定されたもの)する以前に(+)と言う「外部結合演算子」を使った例が既に存在しているので
必要な情報の補足は既に成されていたってことね。

# まあ、せいぜい言葉遊びに浸っていて下され♪

>>48
>はっきり言うと、君達は「外部結合演算子」を問題にしたいらしい。

したくありません。
フル結合と片側結合の定義を質問してるだけ。
外部結合の一種なんだったら、そう説明すればよいだけの事。

>私にしても君達にしても話題に必要な個所の情報伝達は正しく行えているってことが言いたいのだよ。

一般に使われない言葉を使った段階で、そうでは無いということが言える。
あなたローカルな方言だか造語だかを持ち出して
>必要な個所の情報伝達は正しく行えている
などと良く言えるね。

>そう、解説(規定されたもの)する以前に(+)と言う「外部結合演算子」を使った例が既に存在しているので
>必要な情報の補足は既に成されていたってことね。

何を言いたいのかさっぱりわかりません。
簡単なことは簡単に、難しいことも簡単に説明するのがSEでしょ。

あなたは
>○ a = b(+)
と言った。
もちろんこれはOracleの外部結合であり、SQL92で言うところのLEFT OUTER JOIN
だけど、これと「フル結合と片側結合」はどう関係するんでしょうか？

ひょっとして、フル結合とはFULL OUTER JOINのことですか？
Oracleには完全外部結合はありません。

それから、外部結合・内部結合は「実装」とは何の関係もありません。

正しく用語も使えないのだったら、もう出てこないことですね。
どうせ、聞きかじりの断片的な知識でしゃべってるんでしょ。恥ずかしい。

あぁ、それから、
a = b
の代わりに
a = b(+)
を使えというのは、

全くの誤りであり、デマ

なので、信じないように＞24さん

>>49
面白い奴だなぁ！ (笑
感情を垂れ流して何を訴えようとしているのかね♪

外部結合なんて語彙など様々にあることをもっと知ってくだされ。(ひ弱な知識だと無理みたいだがね)

>>50
デマじゃないよ。
ダイナセットで考えてね♪(おバカさん)

>>51-52

恥ずかしいから、新で、お願いだから。

>>24
>>52みたいなバカがいない、OTNなどで再度質問することをおすすめします。

ふー、ちょっと遊び過ぎたかなぁ？ (笑
でも、愚かなガキんちょ達と遊ぶの楽しいから仕方ないよね♪

# 只今、特別粘着優待券を無料で配布しております。
# この機会を逃さず、奮って粘着君になってくださいね♪

必死だね（藁＞出張32
きみの読んだ専門書とやらの書名でもさらしてみろよ（藁
ここまでレベルを落としてやるんだぜ。
これに答えられないんだったら、書き込みをやめるんだね。
エセSEクン（藁

>>56
> きみの読んだ専門書とやらの書名でもさらしてみろよ（藁

それが通じるのは青尻学生だけ。

>それが通じるのは青尻学生だけ。

俺は出張32がどこで「フル結合と片側結合」などという言葉を仕入れたのか、
どこで「Oracleは外部結合を使うと、100倍から1000倍のパフォーマンスを
獲得できる」なんて知識を得たのか知りたいだけだよん。

デタラメ言って胸を張るSEがどういう書名をあげるのか興味あるしな（藁

>>58
> どこで「Oracleは外部結合を使うと、100倍から1000倍のパフォーマンスを
> 獲得できる」なんて知識を得たのか知りたいだけだよん。

君の読解は変だよ。
「オラクルでダイナセットの場合、フル結合による多段階結合は
パフォーマンスを著しく低下さす要因になる場合がある」って言ってるのですよ♪

「オラクルでダイナセットの場合」というのがまたまた意味不明ですね。
どっからそんな限定が出てきたんですか？
「ダイナセットで考えると、
a = b
の代わりに
a = b(+)
を使うほうがパフォーマンスが良いというのがわかる」
という主張じゃないんですか？

「多段階結合」
いいかげんに造語はやめてください。
一般に使われる言葉じゃないと、相手に伝わりません。
普通に言うと何のことですか？
一般にどういう言葉が使われているか知らないと判断せざるを得ませんよ。

>「オラクルでダイナセットの場合、フル結合による多段階結合は
>パフォーマンスを著しく低下さす要因になる場合がある」
と
>× a = b
>○ a = b(+)
は、どういう関係があるんですか？

>>60
君って実務経験殆どなさそうですね。（汗"

多段階結合(多階層結合)の例です♪
a=b
b=c
c=d
d=f

# ふー、疲れるわ！

>多段階結合(多階層結合)の例です♪
>a=b
>b=c
>c=d
>d=f

多段階結合とは、３つ以上のテーブルを結合することですか？
それから、「フル結合」とは、「等結合」のことですか？

a=b
より、
a=b
b=c
の方が遅くなるのは当然でしょ。何言ってるんですか。

>a=b
>b=c
>c=d
>d=f
が遅い場合どうすればいいんですか？

この現象と、
>× a = b
>○ a = b(+)
は何の関係があるんですか？

Oracleでパフォーマンスが悪い場合、まず何を見ればいいですか？
遅いクエリーを特定するのはどうすれば良いですか？
遅いクエリーが特定できた場合、まずどうすれば良いですか？

何にも答えられないでしょ。

>>61
>君って実務経験殆どなさそうですね。（汗"

あなたは、データベースの素人集団の中で仕事をしているみたいですね。
しかも、自分がどれだけ変なことを言っているのかさえも気づかないし、
指摘されても目をつぶる。

知り合いじゃないことを祈りますよ。

>>63
遅くなるようなクエリーなど一切記述しないから特定する必要は無いんですよ♪
まあ、解析ツール走らして悩んでる輩も多いけどね♪

>>64
あのさぁ、捨て台詞は聞き飽きました。
遅くならないって言い切るのであれば、内部アーキティクチャを示して証明して下され！（笑

>>65
>遅くなるようなクエリーなど一切記述しないから特定する必要は無いんですよ♪

あなたはプログラマーなの？
あなたの手がけるシステムのクエリーは全部あなたが書くの？
パフォーマンスチューニングだけをやることはないの？
あなたが必要ないから、知る必要*も*無いの？

>遅くならないって言い切るのであれば、内部アーキティクチャを示して証明して下され！（笑

遅くならないなんて誰も言ってませんけど。
あなたが、

>>33
>あ！
>もしかして、複数テーブルを関連付ける時にフル結合多様してないですか？
>それって致命的に低速(1/100-1000)になるよ。
>結合式はフルじゃなくて片側結合にして下さいね。
>
>× a = b
>○ a = b(+)

なんてことを言うから、それは
「ウソ、デタラメ」
ですって言ってるんですけど。

発言を続けるならせめて
「フル結合」
「片側結合」
「多段階結合」
を普通どういうか位は示してください。
ANSI(ISO) SQLの用語でもOracleの用語でもかまいません。英語でもかまいません。

>>66
> パフォーマンスチューニングだけをやることはないの？

無いね。(つまらんから)
チューニングが大切であること当たり前。
但し、事後チューニングに頼り過ぎるのはド素人。

>>× a = b
>>○ a = b(+)

> なんてことを言うから、それは
> 「ウソ、デタラメ」
> ですって言ってるんですけど。

だから、君の読みが浅いだけなんだって...!(汗"
どのような条件だと遅くなるか等を説明してもムダなので
何方でも出来る簡便式を提示したまでのこと...

# そんなものに意固地になって突っ込みを入れる貴方は未熟者ってことだよ。

>但し、事後チューニングに頼り過ぎるのはド素人。

究極的には、実運用してみないと、パフォーマンスってわからない
ものなんですけど・・・。
だから、パフォーマンス情報を収集する必要もあるし、事後に問題
部分を切り分ける必要も出てくる。

>だから、君の読みが浅いだけなんだって...!(汗"

違います。

>もしかして、複数テーブルを関連付ける時にフル結合多様してないですか？
>それって致命的に低速(1/100-1000)になるよ。
>結合式はフルじゃなくて片側結合にして下さいね。

の部分は、何を言ってるかさっぱりわかりません。
だから単語の質問をしているんですよ。理解出来ませんか？

>× a = b
>○ a = b(+)

の部分は完全にウソ。
このような置き換えは普通出来ません。

ある特定の条件下では（両者の結果セットが同一の場合）、どちらを
使っても同じですが、おそらく後者の方が遅いでしょう。
オプティマイザが同じ実行計画を出すかもしれませんけど。

>どのような条件だと遅くなるか等を説明してもムダなので
>何方でも出来る簡便式を提示したまでのこと...

ではなくて、あなたは「ウソの改善策」を提示したのです。

># そんなものに意固地になって突っ込みを入れる貴方は未熟者ってことだよ。

よく「そんなもの」なんて言えますね。
質問者はあなたのウソの為に、無駄な時間を消費したのかもしれないんですよ。

適当なことしか言えないのであれば、発言を止めてください。

>>68
> 究極的には、実運用してみないと、パフォーマンスってわからない
> ものなんですけど・・・。
> だから、パフォーマンス情報を収集する必要もあるし、事後に問題
> 部分を切り分ける必要も出てくる。

それ当たり前の理屈です。(発言する意味すらないよ)
よって、
但し、事後チューニングに頼り過ぎるのはド素人。

>>× a = b
>>○ a = b(+)
> の部分は完全にウソ。
> このような置き換えは普通出来ません。

> ある特定の条件下では（両者の結果セットが同一の場合）、どちらを
> 使っても同じですが、おそらく後者の方が遅いでしょう。
> オプティマイザが同じ実行計画を出すかもしれませんけど。

実際にやってから発言してくれ！ (笑
現実にどこでも使われている。(使ってなけりゃＤＢが単純構造か無知だと思う)

勿論、全てのクエリーが早くなる訳じゃないぞ！ (アホ君らしいので忠告しとくね)

>>69
>実際にやってから発言してくれ！ (笑

実際にやってくれもなにも、

> このような置き換えは普通出来ません。

ので、出来ません。
だから「ウソ」だと言ってるんですが、いいかげんわかってください。

なにかと勘違いしてるんじゃないですか？

>現実にどこでも使われている。(使ってなけりゃＤＢが単純構造か無知だと思う)

よってこれもウソ。恥の上塗りはやめましょうよ。
ひょっとして、
「等結合でも左外部結合でも常に同一の結果が返ってくるスキーマ」
を常に作ってるということですか？
信じられない。

>実際にやってから発言してくれ！ (笑

というか、Oracleのオプティマイザの実行計画ベースで内部的に「何」が使われるから
「速くなることがある」のか説明してください。
質問の意味がわかりますか？わからないだろうな・・・。

>>68

>>× a = b
>>○ a = b(+)
> の部分は完全にウソ。
> このような置き換えは普通出来ません。

ほい、正確には嘘だよ。(突っ込む個所かぁ?)
正確には、
× a = b
○ a = b(+) And b != NULL

だわな！ (笑

aがNULLならって突っ込みするなよ。(虚しいからね)

>>71
>正確には、
>× a = b
>○ a = b(+) And b != NULL

なるほど。最初からそう書けばいいのに。
で、
フル結合 = 等結合
片側結合 = 左外部結合
ということであってますか？

>a = b(+) And b != NULL
とやると、なぜ速い（速くなることがある）のですか？
パーサの速度は同じとしましょう。
Oracleのオプティマイザの実行計画ベースで議論できるはずです。
言ってる意味がわかりますか？

>>72
あまりつっこむのもかわいそうですけど（笑

>a = b
と
>a = b(+) And b != NULL
の結果は等価ではありません。
こんな間違いをするとは・・・。

>>72
だからさぁ、パフォーマンスが著しく低下するようなクエリー作って実験してみろって．．（汗"

>>73
あんまり突っ込んであげないで....(汗"
等価であるのならパフォーマンスに大きな違いが出るわけないしね。

>>74
>等価であるのならパフォーマンスに大きな違いが出るわけないしね。

あー、何が「等価でない」のかわかってない模様。
「結果」が等価でないんですけど・・・。
やってみればすぐにわかるのに・・・。

>>75
> 「結果」が等価でないんですけど・・・。
> やってみればすぐにわかるのに・・・。

うん、そうだね♪
で、君もアホアホ突っ込み君なのですね♪

やってみました。
あまりに遅いので途中で中断。

Oracle8i Release 8.1.6.1.0 - Production
JServer Release 8.1.6.0.0 - Production
に接続されました。
SQL> desc t1
名前 NULL? 型
----------------------------------------- -------- ----------------------------
CODE NUMBER(38)
S VARCHAR2(16)

SQL> desc t2
名前 NULL? 型
----------------------------------------- -------- ----------------------------
CODE NUMBER(38)
S VARCHAR2(16)

SQL> select count(*) from t1;

COUNT(*)
----------
1048576

SQL> select count(*) from t2;

COUNT(*)
----------
1024

SQL> select count(t2.s) from t1, t2 where t1.code = t2.code;

COUNT(T2.S)
-----------
268435456

経過: 00:08:28.45
SQL> select count(t2.s) from t1, t2 where t1.code = t2.code(+) and t2.s is not null;
select count(t2.s) from t1, t2 where t1.code = t2.code(+) and t2.s is not null
*
エラー行: 1: エラーが発生しました。
ORA-01013: ユーザーによってカレント操作の取消しが要求されました。


経過: 00:22:02.31

次は、速くなるパターン教えてください。
やってみますから。

>>78
全然出来て無いじゃん！(笑

> パフォーマンスが著しく低下するようなクエリー作って実験してみろって．．（汗"

良くお読み下され！ (爆笑

>>79
あなたは、「速くなる方法」を提示したんですよ。
何か例を示してください。

例が示せないなら、オプティマイザベースの話でも結構です。
「何」が使われるようになるから速くなるんですか？

それから、あなたはパフォーマンスに関して何か勘違いしてますね。
理想的な最速の実行時間なんて誰もわからないんですよ。
あくまでも、チューニングは相対的なものです。

select count(t2.s) from t1, t2 where t1.code = t2.code;
は、私に言わせれば、
>パフォーマンスが著しく低下するようなクエリー
なんです。もっと速くなる方法を探してるんです。

どうすればいいんですか？
「フル結合」をやめて「片側結合」にしたけど駄目でしたよ。

実例を出したら、とたんに腰が引けましたね（笑
もっと何か質問しなければならないことがあるんじゃないですか？
思いつきませんか？（笑

ﾊｧ、またＳヨが暴れてるねぇ。
相手しないほうがいいよ、時間の無駄だから＞相手してる人

>>82
いえ、もうちょっと相手します（笑

>>出張32氏
そうそう、これぐらいは答えてくださいよ。

>フル結合 = 等結合
>片側結合 = 左外部結合
>ということであってますか？

もう出典は追求しませんから。

まとめます。

私は、
>× a = b
>○ a = b(+) And b != NULL
の後者は前者と同等のパフォーマンスか、ほとんどの場合遅くなる、と主張しています。

あなたは、
>もしかして、複数テーブルを関連付ける時にフル結合多様してないですか？
>それって致命的に低速(1/100-1000)になるよ。
>結合式はフルじゃなくて片側結合にして下さいね。

と主張しています。
私はそれが誤りだと主張しています。
あなたが、なんの根拠も示さないため、「うそつきよばわり」もしています。

私はそれが誤りであることの一例（反例）も示しました。
どう反論すればよいかおわかりですよね？

>>84
全然まとめになってません。
ちゃんとテストをして下され！
君の示したテスト結果は全く意味をなさないことを理解して下され！

# それと、私は優しくないのでバカに手取り足取り無料で教える気など御座らん！
# 有意義な情報を掴みたいのなら自身で努力して掴んで下され。
# (アドバイスして貰っただけでも感謝してね♪)

>全然まとめになってません。
そうですか？

>ちゃんとテストをして下され！
してますけど。

>君の示したテスト結果は全く意味をなさないことを理解して下され！
根拠は？

># それと、私は優しくないのでバカに手取り足取り無料で教える気など御座らん！
># 有意義な情報を掴みたいのなら自身で努力して掴んで下され。
># (アドバイスして貰っただけでも感謝してね♪)

うそつきのあなたに言われても説得力ありませんね。
逆に、自分の常識がもはや常識ではないことに気づいたでしょ？
感謝してね♪

そうそう、これぐらいは答えてくださいよ。

>フル結合 = 等結合
>片側結合 = 左外部結合
>ということであってますか？

もう出典は追求しませんから。

>>86
>>君の示したテスト結果は全く意味をなさないことを理解して下され！
>根拠は？

自分で考えれ！ (バカに教える気はない！)

> うそつきのあなたに言われても説得力ありませんね。
> 逆に、自分の常識がもはや常識ではないことに気づいたでしょ？
> 感謝してね♪

うん、助かるよ。
君のような輩にアドバイスを利用されちゃ堪らねえからな！

# 愚か者は何時までも愚か者で居て下され！（笑
# ってことで終了にします。

面白いのでage

結局、何一つ具体的なことが言えないのね。
で、こちらから何か言うと、

そんなことはわかってる
説明の必要はない

と繰り返すだけ。

面倒くさいので私も理由なしの発言でいきます（当然全部説明できますけど（笑））

a = b
a = b(+) And b != NULL

では、通常後者の方が遅くなります。
何故遅くなるのかというと、Oracleの＊が＊を＊した結果、＊からです。
これは、＊で＊とすれば確認できます。
まれに、同一のパフォーマンスになる場合がありますが、これは
＊が＊の場合です。

さて、都市伝説とでも言えるこの手の類のものは良く聞きます。
a = b and b = cより
a = b and b = c and c = a
のほうが速いとか。

これは、＊が＊するときにどうやって＊を決め、内部でどういうふうな処理が
行われるかを知らない人間が言うことです。
確かに、ある特定ベンダーの特定バージョンではこうしたほうが一般に速く
なるということもあります。そして、その情報は、そのベンダーのテクニカル
エンジニアからもたらされたりもします。
しかし、これは＊の＊が＊である場合の話で、普遍的な話ではありません。
＊の＊が＊の時には良くあった話なのですが、最近では＊も＊し、＊も＊
ので、この類の裏テクニックとでも言える者は少なくなりました。

最近のOracleなどでは、その内部処理も公開され、一般の書籍でも解説されているので、
それが本当に速いのかどうかは＊の＊が＊を＊かどうか確認してみることでわかります。

では、「一般に遅いクエリー」というのはあるかというと、それはあります。
例えば＊のようなクエリーの場合、＊に＊を使っているため、ほとんどどの＊も
＊で＊を使うと＊するので、＊よりも確実に遅くなります。
逆にいえば、クエリーのコーディングレベルで言うと、このようなコーディングを
避ければよい訳です。

さて、あるクエリーが数分かかる場合、・・・

>>90
あんた根本的に間違ってるぜ。
それを世間一般では机上の理論と呼ぶぜ。

面白いんで見てました。

出張32さんのいう

>× a = b
>○ a = b(+)

っていう奴の理由が知りたい。
googleでは片側結合っていう日本語ではヒットしなかったな。
別にどっちを煽ってるっていうんでもなく、知らなくて恥掻いたら
いやだから知りたい。デマだったらデマっていう結論でもいいけど。

とりあえずどっちもガンバレ。実はおれもplatinum。

>>91
あんた根本的に間違ってるぜ。
それを世間一般では机上の空論と言うぜ。

空論でも、ないよりマシ
一般的DBMSの動きを勉強せず、
特定ベンダーのDBマニアは、使い物にならん！

そして話は超低レベルを彷徨い続ける♪

# まあ、アホアホしてて下され。

おもろいからage
ちなみに私の専門はDB2で、Oracleはそんなに詳しくないんだけど
私の経験から言っても外部結合なんて原則禁止。要件上やむを得ず
行う必要がある場合のみ、JOINするテーブルの件数等を加味した上
でGOサインを出してます。
a = bをフル結合と呼ぶのもここで始めて知りました。(ｗ
フル結合と聞けばFULL OUTER JOINを連想するのが極常識的なDB
エンジニアじゃないかな。
むー、やはり出張32の旗色が悪い。というか出鱈目では？

出張32の負けかぁ。
なーんだ。

>>96さん
なるほど、そらそーですよね。自分はOracleはもういいから
そろそろDB2をいじくりまわしたいと思っています。

あとはSQLServerがどんな感じかご存知の方がいたら聞きたいですね。
個人的にはこの3つおさえればほぼデファクトだと思います。

>>82さん
どちらのことを言っているのですか？客観的には出張32氏の方が
暴れてるように思えます。

90さんの伏字を部分について思う回答としては、

実際にexplain して言っているわけではないのでウソ言ってたら勘弁、ですが

a = b
a = b(+) And b != NULL

a = b の場合は索引検索だけで結合する相手が存在するかどうか判定できるのに対して
a = b(+) の場合は取得した結果を判定する必要があるので必ずデータを
引っ張ってこなくちゃならんですよね。ディスクアクセスがその分増えると
なれば常識的に後者の方が遅くなるはずと思います。

b表がちっちゃい表だとかインデックスが張ってない、とかだったら別ですよ。
ちっちゃい表だったらstar問い合わせせいや！とか、全表キャッシュ指定した方が
早いや、となります。
でっかい表でインデックスが張ってなかったらどっちみち全表検索になるので
!=null の判定が早いのか、a=b　の判定が早いのか、どちらか？となるので
机上では結果はわかりません。

ということでいかがか？

すいません、>>99　はoracle に特化した話で普遍的な
話ではありません。ｽﾏｿ

>>98
自分はIBM系列なんで、DB2だけ知ってても一応仕事にはなるん
ですが、最近のDB2はほとんど投売りでOracleのシェアを奪おう
という戦略に出ています。その結果OracleからDB2への移行案件
なんかも増えてまして、正直Oracleも勉強しないとあかんのです。
Oracleは半年ほど経験がありまして、GOLDぐらいの知識はある？
はずなのですが、それでもキツイっすね。もう一段上を目指さな
ければ♪

ご存知でしょうがDB2はOracleと違って巷に流通している情報が
圧倒的に少ないです。（一般書籍で出回り始めたのもここ最近です）
オプティマイザの仕様もブラックボックスですし、Linux用のDB2で
さえソースは公開されてません。
また同じ用語でもOracleのそれとは微妙に定義が違っていたりします。
そのあたりがとっつきにくいと言われる所以でしょうか？

>>101
ＭＳもMSDE等によってOracle駆逐の戦略を打ち出しています。
ＤＢエンジンだけのメーカーにとっては非常に辛い環境と言えるでしょう。

尚、用語に拘りだすと製品に振り回されることに通じますのでご注意くださいませ。

# SQLSreverの6.5は動的カーソル制御に置いて不備があり使いづらかったね。
# まあ、7.0以降はそこそこまともになって喜ばしいことです。

　　Teradataの話はないっすか？
　　ないっすか。

先日のDB2フェアってどんなかんじでした？

>>103
ないっす。
所詮、テラバイトの世界はまだまだ制約が多いだけです。

データベースファイルを圧縮できるＤＢソフト作ればＯｒａｃｌｅなんてすぐに追い抜けると思うが。

☆★楽してお小遣い★☆
簡単・安心・在宅ワーク可能
興味のある方は下記をクリック！！
http://members.aol.com/hnworld/

teraユーザの社内SEです。

>27

>ハッシュでディスク上にばら撒くだけで早くなる？
>ぺんてぃあむを並べただけの機械であれだけスピードが出るのは
>不思議なのですけど．．．

私なりの理解ですけど・・

SQL鯖とか、ORACLE（あんまり詳しくないけど,）とteraの大きな違いは,
データの物理的格納方法でしょうね。
#ハッシングは,他のRDBMSでもやってますよね。

teraは、Bツリー系じゃないんですね。
ハッシングされたテーブルデータを,
物理ディスクのシリンダー、ブロックの空いてるところに
シーケンシャルにデータを埋めていく、って感じかな？

データの論理的な構造と、物理的格納が近いっていうか。

そのせいか、大量バッチ処理で、full　table　scanかかっても、
そこそこパフォーマンス出ます。
その代り,OLTPオンラインリアル処理には、
弱いっす。

あ〜、うまく書けない。（鬱

>103

何について知りたいのか分かりませんが
さっき書いた以外の特徴を思いつくまま列挙すると,

1)index張らなくても、結構パフォーマンス出ます.
2)だから、正規化しても,パフォーマンス出ます.
3)当然、ハードが,NCR製に限られてしまう.（たぶん）
4)チャネルも、特製のやつですね。
5)NT版もあったような・・・
6)並列台数増やせば,ほぼ線形的に速くなります.
7)カーソル処理ができない、もしくは苦手
8)お値段はそれなりにしたはずなので、
　　中小規模のユーザには敷居が高いかも.
9)マイナーな存在なので,いろいろ覚えても,
　　転職時にウリになりにくそう^^;

といったところかなぁ。

Oracleも、でキーの数が少なければ、bitmap Indexだと早いって聞いたんですが、
うまく使えば結合が早くなると思ってます。
実際使っている人のかんそうはどうでしょうか？

知らないので確認したいのですが、
teraのハッシュ値というのは、主キーから求めてるんでしょうか？
知っている人がいたら教えてください。

DB2とOracleのアーキテクチュアとか機能の違いって、どんなかんじなんでしょうかね。
私は、いままで、Oracle使ってきましたが、これからＤＢ２になりそうなんで．．．


余談ですが、
出張32は、データ設計が重要と言いたいんでしょうけど、
広く浅い知識でDBMSのことまで偉そうに首突っ込んでるのが恥ずかしいですね。
それに、適当な用語（「フル結合」とか「片側結合」とか）使ってるし．．．

>広く浅い知識でDBMSのことまで偉そうに首突っ込んでるのが恥ずかしいですね。

そうそう　後は適当にごまかすしね

おもしろいよ　彼

多分そんな仕事してるんだろうね

いい身分

　　　　彡ミミミヽ ﾉ彡ミミ)
　　　((彡ミミミミ))彡彡)))彡)
　　　彡彡ﾞﾞﾞﾞﾞ"ﾞﾞ""""""ヾ彡彡)
　　　ﾐ彡ﾞ　..＿ 　　　＿ 　 ﾐﾐミ彡
　　((ミ彡 '´￣ヽ '´/￣　｀ ,|ミミ))
　　ミ彡　 '￣￣' 　〈￣￣ .|ﾐミ彡
　　ミ彡|　　） ）　| |　｀（ （　|ﾐ彡
　 ((ﾐ彡| 　（ （　-し｀)　） ）|ﾐﾐミ　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　 ゞ|　 ） ）　 ､,!　」（ (　|ソ　　　＜　このスレはよく頑張った。感動した！ 終了！
　　　　　ヽ（ （￣￣￣' ) ）/　　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　,.|＼､)　 　　' ( ／|､
　　￣￣| ｀＼.`──'´／ |￣￣｀
　　　　　 ＼　~＼,,／~　 /
　　　　　　　＼／▽＼／
　

>>110
結合を前提とするなら、Bitmap Join Indexを使ってみるのは如何

>110
>teraのハッシュ値というのは、主キーから求めてるんでしょうか？

確かそうだったと思います。
主キーの値をハッシング関数に放り込んだ結果、どこの
仮想ディスクに割り当てるか決めるんじゃなかったかな？
だから、主キーの値に偏りがあると、きれいにハッシング
されないこともあり得るんですが、
ウチでは、割ときれいにばらけてるみたいです。

それと、主キーは、ユニークキーである必要はないです。

>>115
なるほどありがとう。
で、主キーが複数カラムのときはどうなるんでしょう？
主キーすべてを指定したときは早いが、主キーの一部を指定したときは
遅いってことなんでしょうか．．．

>だから、主キーの値に偏りがあると、きれいにハッシング
>されないこともあり得るんですが、
>ウチでは、割ときれいにばらけてるみたいです。
うまく設計されていれば主キーはばらけるのでそのあたりは大丈夫ですね。
主キーに偏りがあるのは、もともとデータ設計が悪いということになりますから。

>>114
>結合を前提とするなら、Bitmap Join Indexを使ってみるのは如何
なるほど、確かに。
ただ、とりうる値が、１０個とか言うレベルじゃなくて、数百くらいでも結構実用的だみたいな
ことを聞きましたが、そのあたりの感覚を聞きたいんです。
bitmapと聞くと、どうしても、フラグや区分など、とりうる値が少ないものにつけるのが定石ですが、
じつは結構適用範囲が大きいのかなと。
区分テーブルがあって、区分名称なんかを表示するのに結合するときは使えないんでしょうか？
また、数百くらいの種類のコードだったらbipmapでindex張っちゃってもいいかなと思って。

>>115
>だから、主キーの値に偏りがあると、きれいにハッシング
>されないこともあり得るんですが、
ハッシングって、本来、キーの値に偏りがあってもきれいにばらける
ようにすることですよね。それともＴｅｒａが提供するハッシュ関数が悪いってこと？

>110
>で、主キーが複数カラムのときはどうなるんでしょう？

トランザクションデータの場合,主キーは複数カラムの
組み合わせになるのが普通ですよね.

たしか、複数カラムをくっつけて,ハッシング関数に放り込むと、
何個目の仮想ディスクにデータを入れるべきか出てくる,
という仕掛けだったと思います.

>主キーすべてを指定したときは早いが、主キーの一部を指定したときは
>遅いってことなんでしょうか．．．

ウチの場合,主キー以外の索引インデックスって貼ってないですね.
それでも、パフォーマンスが出るのがteraの強みだと思います.
主キー全部指定した検索なら,より速いと思いますが,
DWH要件だと、索引時に指定するキーって、
すごく不特定多数になるので,実際にはほとんどfull　table　scan
で動いていると思います.

>117

>ハッシングって、本来、キーの値に偏りがあってもきれいにばらける
>ようにすることですよね。
>それともＴｅｒａが提供するハッシュ関数が悪いってこと？

これは、私の書き方が悪いですね.
まず、主キーがユニークなら通常問題ないと思います.

主キーがユニークじゃない場合に、キーの値の種類が少ないと、
どっかの仮想ディスクに、データが偏るという事がありえます.

teraでパフォーマンスを意識しなきゃいけないデータ件数
（数100万件レベル？）で,主キーがまったく同じレコードが、
大量に存在するケース、ってのは、避けるべきなんでしょうね。

たとえば、売上伝票のトランザクションのばあい、
特定の商品がたくさん売れるってのはありえますよね.
この場合,商品コードのみを主キーにすると、
上記のようなことが起こるので,
商品+得意先+売上日付をキーにするとか,
それでもだめなら,伝票連番みたいなのを機械的に振って
それを主キーにするとか.

長文スマソ。

横から失礼します。

>108,110
良く誤解される方が多いのですが、
主キーは論理設計時の概念で、ユニークでなければなりません。
テラがハッシングに使用しているのはプライマリーインデックスです。
これは、テラ固有の概念で"CREATE TABLE"時に明示的に指定します。

>117
おそらくは、レンジ分散での『偏り』と混同していると思われます。
テラで言うところのプリマリーインデックスの『偏り』とは、重複値
のことです。（108さんの具体例を参考にして下さい）

そうすると、これからDB導入を検討するならOracleってこと？

１ユーザーの意見として、一言言わせてくれ。
Ｕ−ＤＢもＯｒａｃｌｅも競争は結構だが、
頼むからもうちょっとＶｅｒＵＰのスピード落してくれ。
せめて５〜６年は安心して使える環境にして欲しい。
スクラップ＆ビルドで３年程度でシステム更新かけるような
業界はむしろ少ないんじゃないのか？
横レススマソ。

>>122
いいこと言った！
つーか，漏れはOracleばっかりの人間だが，
最近，おなかいっぱい。

厨房質問で申し訳ありません。今度unix上にあるteradataからデータ
を抽出しなければならなくなりました。当方クライアントの環境はwin2000
です。やはり専用のツールが必要なのでしょうか？？vbとかvbaでは
アクセスできませんか？？どなたか教えてください

VBから出したいならODBC使えば？
遅いけど

ＮＣＲのWin CLIとか使うんじゃないかな。
ただ、テラから大容量のデータを抽出したい場合、注意必要かも。
一度テラのコントローラみたいなマシンのディスク経由でアクセスに
なるけど、そこは大容量ためられない。少量検索向き。

ODBC 経由でふつーにアクセスできますよ．
大量に出力したいなら FastExport をどうぞ(別売だけど)．

そうそう，Perl なら DBD::Teradata というものもあります．．
2.0 から売り物になってしまいましたが，1.x は CPAN にあります．
＃今見たら CJAN になってる．．．

Oracleはもういいよ。。
IBMに大政奉還。

＃最近いい意味でも悪い意味でもIBM変わったな。
＃煮るなり焼くなり好きにして。

age

バージョンアップ結構。
ただし、旧バージョンのサポートを打ち切るのは許せん。
旧バージョンのユーザーに対しては、脅しとしか思えない
言い方でバージョンアップを迫るのはいい加減やめろ。

SBCは120TBなんだぞ!!!動くんだぞTeraは!!

ｼは四系のｼ

やっぱRedBrickでしょ！！

>>134
そういえば、以前あったな〜(^^；
どうしたんだろ、まだ売っているんだろうか

（＾＾）