- - PR -
SQL?
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-10-09 13:10
>>ほむら様
私も結構最近知ったことです。 一例となるのかどうかもわかりませんが・・・。 下記のSQLを実行してみます。 -------------------------------------------------------- Select to_char(sysdate,'YYYYMMDD') From Dual -------------------------------------------------------- 結果として列名が大文字に置換されて表示されると思います。 また、#小文字で#データ型を指定してテーブルを作成、 DESCなどのコマンドで構造を参照すると 列の型名は大文字で表示されます。 このことからも何らかの置換処理が行われていることは間違いないと思います。 正確な表現でいくと「英字を大文字で管理している」となりますかね。 ※実行計画等、いろいろと試したわけでは無いので実際の速度測定などは出来ていません。 
# #部分を追記。 [ メッセージ編集済み 編集者: Crime 編集日時 2003-10-09 13:15 ] | ||||||||
|
投稿日時: 2003-10-09 13:20
DBのチューニングが先という意見の方もいらっしゃるようですが．．．
私は、アプリケーションのチューニングが先だと思います。 特にDBのファイルで自動拡張のパラメータを有効にしていたりする場合は!! あっと言う間にディスクが食潰されます。 DBのチューニングを先にやってしまうと、おかしなSQL文を実行していても 気づかない場合も出てきます。 DBのチューニングより、アプリ(SQL)のチューニングが先です。 | ||||||||
|
投稿日時: 2003-10-09 13:35
>>Masa様
>DBのチューニングが先という意見の方もいらっしゃるようですが．．． 申し訳ありません、私が「DB (or SQL) 」と書いてしまったので、 もしかしたら「DBのチューニング」という表現にSQLのチューニングが入っている方も 居られるかもしれません。 それと、 >DBのチューニングより、アプリ(SQL)のチューニングが先です。 とのことですが、私は「アプリのチューニング」といいますと、 今回の場合は「SQLの結果に左右されない部分」という方向でとってしまいます。 ※Ex）プログラム内で同じ関数を余計な回数呼んでいて・・・など。 それぞれの取り違えもあると思いますが、 「SQLのチューニングはDBあってのもの。」と思ってしまう私でした。 ※Oracle初期化ファイルの最適化などをしていないと、 どうしても遅くなる場合などもありますからね。 同様にテーブル設計等も影響度「大」ですので。 | ||||||||
|
投稿日時: 2003-10-09 13:46
もしかして、
で、５０件ずつ５千回？？そういう意味ではないのですが・・・ 一度に２５万件表示しても、つまりDataGridを使うというところですが、人間が２５万件のデータを見て一度に編集したりその他活用しますか？せいぜい数百件がいいところでしょ？だったら、１００件だけ取り込んでいったん表示し、その中になければ次の１００件を探しに行く…結果的に２５万件処理できるけれども、アプリケーションに取り込むのは件数を絞りませんか、、、という意味だったのですが。 ＞ほむらさん IN句の件数は、Oracle9iのマニュアルをあたったところ、制限はないようです。昔、７の頃に２５６件という制限があったような気もしますが。ただ、SQL文のバイト数は６４キロバイト（ただし、Data Providerでさらに制限される可能性あり）なので、こちらに引っかかっていたのかもしれません。 ＞Crimeさん Oracleの開発をやっている元同僚の友達によると、「そんなん、大文字だけにきまっとうやん」・・・だから、何が決まってるねん(^^; ちなみに、ダブルクォーテーションでくくれば、小文字も解釈します。 ＞自分 >DataAdapter.FillメソッドはDataTableも受け付けるので System.Data.Common.DbDataAdapter.Fillですね。 データセットを渡すと、データテーブルを作ります。データセットとデータテーブル名を渡すと、その名前のデータテーブルがあるか調べ、なければ作り、あれば追加します。 オブジェクトを生成するのに若干時間がかかるので、データセットを渡すよりデータテーブルを渡す方が高速化を期待できる、と思います。 | ||||||||
|
投稿日時: 2003-10-09 13:55
ども、ほむらです。
鶏卵の問題なのかもしれませんし、状況次第のようにも思えますが 僕としても、アプリのレスポンスに問題があるというのならば ＤＢのチューニングが一番最初にくるべきだと思っています。 --------- 僕としても表面的な部分しか知りませんが、 テーブルの設計を見直すだけでもレスポンスはかなり変わってくるように思えます。 特に正規化やインデックスの使い方は大きいと思います。 ＳＱＬやアプリのレスポンスが多少悪くても許容範囲内であれば テーブル設計の見直しだけのほうが良いのでないでしょうか？ 上方修正するのなら広域個所で影響ある部分にしたいかなと。。 プログラムなどで対応してしまうとすべての個所で同じ問題が残ってしまいます。 僕はそう考えるのはSQLを見直すのはまずDBのチューニングからですね。 まぁ僕が出来るのはインデックスを張って正規化する程度ですが。。。 | ||||||||
|
投稿日時: 2003-10-09 14:15
ほむらです。
Jiita氏へ
僕言う、byte制限というのはこっちの話ですね。 でも64KBということはヒープ1ページ分はOKということですか。 実質制限無いようなものですね。 64bit版になったら増えるのかな？(Oracle10g 64bitとか) IN句の部分は結果セットを仮想的に作っているんじゃないかなとということで 制限は考えてなかったんですけどね(じゃないとSELECT句使えないしｗ) 結局は OleDbDataAdapter1.SelectCommand.CommandText の部分がどこまでバッファを持てるかですよね。 ＃RDBがoracleに少しずつ限定されつつある罠w | ||||||||
|
投稿日時: 2003-10-09 14:27
>>Jitta様
>だから、何が決まってるねん(^^; 仕事中に噴きました。何が決まってるんでしょう 
>ダブルクォーテーションでくくれば、小文字も解釈します。 コーディングの時はエディタ等で置換が良いですね
>Oracleの開発をやっている元同僚の友達 ハイディ、もしくはウェンディの存在はやはり癒されるのか、聞いて貰えませんか？
| ||||||||
|
投稿日時: 2003-10-09 18:01
うーん、日本語って難しいですねぇ。笑） 日本人なのに．．． >>Crimeさま >「SQLのチューニングはDBあってのもの。」と思ってしまう私でした。 >※Oracle初期化ファイルの最適化などをしていないと、 > どうしても遅くなる場合などもありますからね。 > 同様にテーブル設計等も影響度「大」ですので。 >>ほむらさま >僕はそう考えるのはSQLを見直すのはまずDBのチューニングからですね。 >まぁ僕が出来るのはインデックスを張って正規化する程度ですが。。。 言葉が足りていなかったようです。 私が言いたかったDBチューニングとは、キャッシュへのメモリ割当など DBMSサーバの動作に影響するレベルのチューニングのつもりでした。 プロジェクトのメンバが、一定のレベルで特に意識しなくても訳の分か らないプログラムを作ったりしない場合にはまったく問題ないでしょうが、 中に新人など素人同然のメンバが混じったりすると世にも恐ろしいSQL文 を考えもなしに実行したりしてしまいます。 そんなときに、DBMSサーバのチューニングを行っていると、そこそこの 処理速度で実行されたりするので、とんでもない目にあうことがあるかなぁ と．．．。 Oracleで言えば、実行計画を参照したときに、「Nested Loop」の中で大 量データの「Full Scan」が実行されていたりとか．．． しかも、それが繰り返されていたりとか．．． | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。