ストアドよりインデックスのほうが速いよ
なんかね、データベースからデータを取得して VB で簡単な加工して、
書き戻すっていう更新処理があったのよ。当然、C/S 間のピンポン多発で
非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
上司に言ったわけです。勇気をふりしぼって。
そしたら「ストアドよりインデックスのほうが速いよ」って。(ﾟДﾟ)ﾊｧ?
「クエリ単体の実行時間は 50ms 以下なので遅いのは呼び出しのオーバーヘッドが…」
「データベースが遅いのはね。インデックスなんだよ。たとえば、君の言う
50ms がインデックスを工夫することで 20ms になったら倍以上に速くなるんだよ。」
「いや、50ms が 20ms になっても体感できないと思うんですが…」
「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
言ってるんだよ。インデックスは奥が深いんだよ」
「いまでも主キー指定での取得になっていて…」
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」
書き戻すっていう更新処理があったのよ。当然、C/S 間のピンポン多発で
非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
上司に言ったわけです。勇気をふりしぼって。
そしたら「ストアドよりインデックスのほうが速いよ」って。(ﾟДﾟ)ﾊｧ?
「クエリ単体の実行時間は 50ms 以下なので遅いのは呼び出しのオーバーヘッドが…」
「データベースが遅いのはね。インデックスなんだよ。たとえば、君の言う
50ms がインデックスを工夫することで 20ms になったら倍以上に速くなるんだよ。」
「いや、50ms が 20ms になっても体感できないと思うんですが…」
「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
言ってるんだよ。インデックスは奥が深いんだよ」
「いまでも主キー指定での取得になっていて…」
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」
|
|
|
2 ：NAME IS NULL：04/09/03 12:36 ID:???
もっと分かりやすく文章かけよ
何がいいたいのかﾜｶﾝﾈ
何がいいたいのかﾜｶﾝﾈ
3 ：NAME IS NULL：04/09/03 21:24 ID:???
スレ建てないで雑談スレに書けよ
4 ：NAME IS NULL：04/09/04 00:23 ID:???
>>1 削除以来出しとけよ。
5 ：NAME IS NULL：04/09/04 17:00 ID:???
なんだか言っていることが面白いよね。
本当雑談だよ。
入社１年目の初心者でしょ。
そのあとの話の展開がどうなったのか教えてちょ。
本当雑談だよ。
入社１年目の初心者でしょ。
そのあとの話の展開がどうなったのか教えてちょ。
6 ：NAME IS NULL：04/09/10 23:52:23 ID:???
7 ：NAME IS NULL：04/09/11 03:47:27 ID:???
>>1
逆にストアドプロシージャでは解決する見込みはないと思うけど、解決すると
判断したその根拠は何だろう。
詳細が分からないから断言は難しいけど、やっぱりインデックスが重要だと
思うなぁ。経験的に。
逆にストアドプロシージャでは解決する見込みはないと思うけど、解決すると
判断したその根拠は何だろう。
詳細が分からないから断言は難しいけど、やっぱりインデックスが重要だと
思うなぁ。経験的に。
8 ：NAME IS NULL：04/09/11 08:05:18 ID:???
9 ：NAME IS NULL：04/09/11 15:25:04 ID:???
こんな感じか？ たとえば、半角全角混在の文字項目を全角に統一する。
(1) レコードセットを取得する。
(2) VBの関数を使って、1レコードを全角に変換して、1レコード分の update 発行。
このようなユーザーの意思を必要としない処理はストアドにして一括更新したほうがいいね。
(2) を何万回も繰り返すのはアホ。
(1) レコードセットを取得する。
(2) VBの関数を使って、1レコードを全角に変換して、1レコード分の update 発行。
このようなユーザーの意思を必要としない処理はストアドにして一括更新したほうがいいね。
(2) を何万回も繰り返すのはアホ。
10 ：NAME IS NULL：04/09/19 02:06:28 ID:Kqi5X+Sq
>>1
そろそろ結果を報告しなよ
そろそろ結果を報告しなよ
11 ：NAME IS NULL：04/10/19 15:09:20 ID:???
12 ：NAME IS NULL：04/10/24 01:21:41 ID:???
>1
ミドルウェアの記述がないので、Java環境での話をすると
以前調べた時、NWとミドルを含めたオーバーヘッドは1,2msだった。
数万件単位で大量件数を処理するならSP化は有効だけど
オンライン系で遅いなら他にボトルネックがあると思われる。
もしかして、毎回コネクション張りにいっているという
オチじゃないだろうな・・
ちなみに、更新系はC/S環境でもSPに匹敵する性能がでるよ。
参照系は、SPには勝てんが。。
ミドルウェアの記述がないので、Java環境での話をすると
以前調べた時、NWとミドルを含めたオーバーヘッドは1,2msだった。
数万件単位で大量件数を処理するならSP化は有効だけど
オンライン系で遅いなら他にボトルネックがあると思われる。
もしかして、毎回コネクション張りにいっているという
オチじゃないだろうな・・
ちなみに、更新系はC/S環境でもSPに匹敵する性能がでるよ。
参照系は、SPには勝てんが。。
13 ：NAME IS NULL：04/11/14 19:15:55 ID:4kWmAqHu
質問：
３層c/sでアプリサーバーとDBサーバーが同じノード上にある場合はストアド使わなくても
パフォーマンス出るんでしょうか？
３層c/sでアプリサーバーとDBサーバーが同じノード上にある場合はストアド使わなくても
パフォーマンス出るんでしょうか？
14 ：NAME IS NULL：04/11/14 19:55:23 ID:cp9oa1wi
15 ：NAME IS NULL：04/11/14 21:55:38 ID:mxx8koKz
>>13
ストアドの方が僅かにでも速くなることが多い
ストアドの方が僅かにでも速くなることが多い
16 ：NAME IS NULL：04/11/14 23:50:30 ID:???
>>2-15
まぁそんなにムキるな。どーせ釣りだろ(ｗ
まぁそんなにムキるな。どーせ釣りだろ(ｗ
17 ：NAME IS NULL：04/11/15 15:01:28 ID:???
18 ：NAME IS NULL：04/11/15 18:56:55 ID:???
19 ：NAME IS NULL：04/11/16 02:03:25 ID:???
>17
たぶん正解だな。
ただ、バカだと思うなら、貴方なりの回答を
聞かせて欲しいものだ。
たぶん正解だな。
ただ、バカだと思うなら、貴方なりの回答を
聞かせて欲しいものだ。
20 ：NAME IS NULL：04/11/20 17:19:37 ID:o6mGJOoN
>12
＞もしかして、毎回コネクション張りにいっているという
＞オチじゃないだろうな・・
そんな気がす・・・
＞もしかして、毎回コネクション張りにいっているという
＞オチじゃないだろうな・・
そんな気がす・・・
21 ：NAME IS NULL：04/11/24 21:01:08 ID:???
>>20
実はデータリンクが IEEE-488。
実はデータリンクが IEEE-488。
22 ：a：04/11/27 09:59:43 ID:SLvZscV9
何回もＳＱＬを発行してない？最近みたプログラムで、カーソルのル
ープ使ってその中でさらに問い合わせを発行して、何万回もＳＱＬを
発行するようなプログラムを見た。
結局、テーブルを結合して一回で問い合わせが完了するようにＳＱＬ
を書き直したら、嘘みたいに早くなったよ。工夫してみれば？
ープ使ってその中でさらに問い合わせを発行して、何万回もＳＱＬを
発行するようなプログラムを見た。
結局、テーブルを結合して一回で問い合わせが完了するようにＳＱＬ
を書き直したら、嘘みたいに早くなったよ。工夫してみれば？
23 ：NAME IS NULL：04/11/28 19:39:51 ID:???
22> ちみはまだ経験が足りん
24 ：NAME IS NULL：04/11/30 02:20:37 ID:???
25 ：NAME IS NULL：04/11/30 05:13:06 ID:???
結合するより、何回もSQL発行した場合も早いこともあるわけで 一概には言えないと？>>23
26 ：NAME IS NULL：04/11/30 12:15:45 ID:???
27 ：NAME IS NULL：04/12/01 01:16:29 ID:???
今更ながら、1の書き込みを読み直してみるとｗ
問題点を通信のオーバーヘッドではないか？と考えているので
>>22さんの意見は、良いところをついているのではないかな。
昔の話だけど実際にそのようなケースを生産性・品質向上
取り組みの副作用として見たことがあるよ。
その時は共通チームが業務共通系の処理を共通関数として
提供してしまった?ため、それに関わるようなマスタテーブルは
そんな処理になってしまった。
最近はマシンも速いから一見遅くはないけど、負荷の高い処理って
なかなか問題が表面化しないで、地雷みたいに埋まってるんだよねぇ。。
問題点を通信のオーバーヘッドではないか？と考えているので
>>22さんの意見は、良いところをついているのではないかな。
昔の話だけど実際にそのようなケースを生産性・品質向上
取り組みの副作用として見たことがあるよ。
その時は共通チームが業務共通系の処理を共通関数として
提供してしまった?ため、それに関わるようなマスタテーブルは
そんな処理になってしまった。
最近はマシンも速いから一見遅くはないけど、負荷の高い処理って
なかなか問題が表面化しないで、地雷みたいに埋まってるんだよねぇ。。
28 ：NAME IS NULL：04/12/01 11:07:14 ID:???
29 ：NAME IS NULL：04/12/24 16:02:31 ID:tUfbN2jS
>>28
たしかに問題とする次元が違ってると思う。
｜非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
｜上司に言ったわけです。勇気をふりしぼって。
インデックス…問い合わせ効率を向上させるためのもの（ツメ見出し）
ストアド…SQL文をプリコンパイル済みにして通常のSQLが問い合わせ前に行う
プリコンパイル作業等に掛かる時間的ロスを軽減する
でなかったか？
バッチ処理するのにインデックスあったら効率悪いので
インデックスをdrop
↓
バッチ
↓
インデックスを(再びCreate)
↓
（シェアードテーブル化できないならSELECT文でキャッシュに）
だろう…
もっと詳しい人どうぞ。（ｗ
たしかに問題とする次元が違ってると思う。
｜非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
｜上司に言ったわけです。勇気をふりしぼって。
インデックス…問い合わせ効率を向上させるためのもの（ツメ見出し）
ストアド…SQL文をプリコンパイル済みにして通常のSQLが問い合わせ前に行う
プリコンパイル作業等に掛かる時間的ロスを軽減する
でなかったか？
バッチ処理するのにインデックスあったら効率悪いので
インデックスをdrop
↓
バッチ
↓
インデックスを(再びCreate)
↓
（シェアードテーブル化できないならSELECT文でキャッシュに）
だろう…
もっと詳しい人どうぞ。（ｗ
30 ：NAME IS NULL：04/12/25 01:07:50 ID:otLeELiy
文面から察するに、SELECTして加工してUPDATEを繰り返してるんでしょ。
加工する内容次第だけど、インデックスよりはストアドじゃないかな。
でも、何もいじらずサーバのメモリ追加した方が楽だったり。
加工する内容次第だけど、インデックスよりはストアドじゃないかな。
でも、何もいじらずサーバのメモリ追加した方が楽だったり。
31 ：NAME IS NULL：04/12/25 01:16:16 ID:ROEABQwC
>>1はACCESSの話してるんだよ。
32 ：NAME IS NULL：04/12/25 09:37:19 ID:ZHJuMAXb
クエリ単体で50ms以下で遅いってことは、
無駄にSQL何回も発行してるのが原因なので
ストアドとかインデックスより、まず処理を見直すべき。
単純なＳＱＬをそのままストアド化しても意味無いよ。
あとインデックスはストアドに対しても有効だよ。
ストアドの実行計画みたことある？
無駄にSQL何回も発行してるのが原因なので
ストアドとかインデックスより、まず処理を見直すべき。
単純なＳＱＬをそのままストアド化しても意味無いよ。
あとインデックスはストアドに対しても有効だよ。
ストアドの実行計画みたことある？
33 ：NAME IS NULL：04/12/25 10:36:17 ID:???
（DB使うのにVB使うのやめれ）
＆
（今の時代アプリにオプソでも良いからDB必ず使え）
∴VB捨てれ
話はそれからだ
＆
（今の時代アプリにオプソでも良いからDB必ず使え）
∴VB捨てれ
話はそれからだ
34 ：NAME IS NULL：04/12/25 11:59:43 ID:???
また、VB も使えない厨が来たのか ?
まず、「（DB使うのにVB使うのやめれ） 」の具体的理由を書いてみそ。
まず、「（DB使うのにVB使うのやめれ） 」の具体的理由を書いてみそ。
35 ：NAME IS NULL：04/12/25 12:05:48 ID:ROEABQwC
ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。
議論の余地なし。
36 ：NAME IS NULL：04/12/25 13:16:43 ID:???
VBアプリでメモリ多く使うと落ちる。
画面のコンポーネントべたべた貼る程度でｷｮﾄﾞる。
画面のコンポーネントべたべた貼る程度でｷｮﾄﾞる。
37 ：NAME IS NULL：04/12/25 13:26:00 ID:j8/J6yiR
まとめて大量のレコードを更新するような処理はテーブルロックがかけられるなら
いいのですが、通常運用中に実行しなければいけないときはどうしてますか？
where無しなどの大域処理をしてしまうと１命令を１トランザクションで実行しよう
とするから、ロックは広い範囲にかかりまくるし、オラクルだとロールバックセ
グメントに書き出しまくる。そのせいか処理が妙に重たい。
ストアドでカーソル使ってwhere current ofで処理しても、ループで内でupdateや
insert命令を実行してもロックやRBSがらみのリソースを消費してる感じです。
仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
それをキーにして数十件ずつコミットしながら更新かけてゆく方法をとったら
俄然処理が速くなりました。
こういうケースでは一般的にはどうするのがいいのでしょうか？
いいのですが、通常運用中に実行しなければいけないときはどうしてますか？
where無しなどの大域処理をしてしまうと１命令を１トランザクションで実行しよう
とするから、ロックは広い範囲にかかりまくるし、オラクルだとロールバックセ
グメントに書き出しまくる。そのせいか処理が妙に重たい。
ストアドでカーソル使ってwhere current ofで処理しても、ループで内でupdateや
insert命令を実行してもロックやRBSがらみのリソースを消費してる感じです。
仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
それをキーにして数十件ずつコミットしながら更新かけてゆく方法をとったら
俄然処理が速くなりました。
こういうケースでは一般的にはどうするのがいいのでしょうか？
38 ：NAME IS NULL：04/12/25 15:33:56 ID:???
＞仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
これをDB内で済ませろ
これをDB内で済ませろ
39 ：NAME IS NULL：04/12/25 15:58:31 ID:???
>29
プリコンパイル(静的SQL)とストアドプロシジャは全く別のものだよ。
プリコンパイル(静的SQL)とストアドプロシジャは全く別のものだよ。
40 ：NAME IS NULL：04/12/25 16:23:54 ID:???
>>38
tempテーブルが使えるならそうするんだけど残念ながらOracle8なので使えません。
ログ運用してるんで通常テーブルをワークには使いたくないのです。
>>39
別の概念ではあるがプリコンパイルされないストアドって見たことはないですね。
tempテーブルが使えるならそうするんだけど残念ながらOracle8なので使えません。
ログ運用してるんで通常テーブルをワークには使いたくないのです。
>>39
別の概念ではあるがプリコンパイルされないストアドって見たことはないですね。
41 ：NAME IS NULL：04/12/25 18:13:53 ID:???
>>40
俺は見たことあるぞ？
俺は見たことあるぞ？
42 ：NAME IS NULL：04/12/25 19:05:05 ID:???
コンパイルといっても構文解析フェーズを済ましておく程度だけどね。
最初の実行時にコンパイルするタイプのを見かけますな。
>>37 はストアドが必ずしも役に立つわけでない例を挙げてみてるんだろうな。
OracleのPL/SQLだと普通の手続き型言語に似てるからとっつきは良いけど
使い方は要注意だ。非効率な変な書き方もできてしまうからな。
最初の実行時にコンパイルするタイプのを見かけますな。
>>37 はストアドが必ずしも役に立つわけでない例を挙げてみてるんだろうな。
OracleのPL/SQLだと普通の手続き型言語に似てるからとっつきは良いけど
使い方は要注意だ。非効率な変な書き方もできてしまうからな。
43 ：NAME IS NULL：04/12/25 19:54:30 ID:???
44 ：NAME IS NULL：04/12/25 20:20:49 ID:M5IwN66m
http://plaza.rakuten.co.jp/batrowa/
ここに行ってゲームのことを一から学ぶ<丶｀Д´>ﾆﾀﾞｰ
ここに行ってゲームのことを一から学ぶ<丶｀Д´>ﾆﾀﾞｰ
45 ：NAME IS NULL：04/12/25 20:37:50 ID:Uriq8RBM
46 ：NAME IS NULL：04/12/26 17:35:00 ID:???
そもそもバッチ更新なのにコンポーネントは全く関係なし。
アプリに負担をかけることすら間違い。
それとクライアントに一端処理を移すとのことだけれども
ストアドやインデックス云々より、DBの構造を見直した
方が早いよ。
アプリに負担をかけることすら間違い。
それとクライアントに一端処理を移すとのことだけれども
ストアドやインデックス云々より、DBの構造を見直した
方が早いよ。
47 ：NAME IS NULL：04/12/29 22:22:41 ID:???
ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。
議論の余地なし。
48 ：NAME IS NULL：04/12/29 23:02:50 ID:???
ボトルネックを調べてみるのにまず手っ取り早い索引から調べるというのは
同意だが、実際の対策としてストアドとインデックスを比べるのは意味はない。
まったく別物だからなぁ。
要領を得ないことをいう部下を信用しないのは上司の基本だと思うな（笑）
同意だが、実際の対策としてストアドとインデックスを比べるのは意味はない。
まったく別物だからなぁ。
要領を得ないことをいう部下を信用しないのは上司の基本だと思うな（笑）
49 ：NAME IS NULL：04/12/30 04:22:19 ID:XdHOAyNH
>>1を叩くのは2ﾁｬﾝﾈﾗの基本だと思うな（笑） ←笑って付けるだけでキモヲタ風味になる。
50 ：NAME IS NULL：05/01/01 17:25:50 ID:+DDcZPR8
つーか どんな業務なのかを教えろよまず。
51 ：NAME IS NULL：05/01/04 23:28:36 ID:gtuR+WFj
>>46-47
ｵﾏｲﾗ、論点がずれてる。
>>48
正解
>>1の場合であればストアドのようなサーバサイドの処理にした方がパフォーマンスが上がると思う。
さらに、可能であれば、『UPDATE ･･･ SELECT』 文にした方がベターだな
ｵﾏｲﾗ、論点がずれてる。
>>48
正解
>>1の場合であればストアドのようなサーバサイドの処理にした方がパフォーマンスが上がると思う。
さらに、可能であれば、『UPDATE ･･･ SELECT』 文にした方がベターだな
52 ：NAME IS NULL：05/01/05 08:57:34 ID:???
53 ：NAME IS NULL：05/01/05 12:16:39 ID:???
54 ：NAME IS NULL：05/01/05 15:41:11 ID:???
>>53
お前こそよく読め。
>「いまでも主キー指定での取得になっていて…」
何で主キー指定して取得してるのにストアドなんだよ？
意味無いだろ。
その点を上司がたしなめたんだろ。
きちんとインデックス張ってまともなクエリ書けと言う意味だろ。
お前はストアドなどとの給う前にやることがあるだろ？と言われたわけだ。
お前こそよく読め。
>「いまでも主キー指定での取得になっていて…」
何で主キー指定して取得してるのにストアドなんだよ？
意味無いだろ。
その点を上司がたしなめたんだろ。
きちんとインデックス張ってまともなクエリ書けと言う意味だろ。
お前はストアドなどとの給う前にやることがあるだろ？と言われたわけだ。
55 ：NAME IS NULL：05/01/05 17:22:32 ID:???
なんつーか、やれやれですな。
>>54
>何で主キー指定して取得してるのにストアドなんだよ？
>意味無いだろ。
ストアドプロシジャの利点は、RDB サーバの _プロセス内で
処理が閉じている_ 点にある。その為、>>1 の指摘する
>C/S 間のピンポン多発で非常に遅いでやんす。
が解消される事が期待できる。
一方、主キーには _既にインデックスは作成されている為_、
二重にインデックスを張る行為には _全く意味がない_。
>>54
>何で主キー指定して取得してるのにストアドなんだよ？
>意味無いだろ。
ストアドプロシジャの利点は、RDB サーバの _プロセス内で
処理が閉じている_ 点にある。その為、>>1 の指摘する
>C/S 間のピンポン多発で非常に遅いでやんす。
が解消される事が期待できる。
一方、主キーには _既にインデックスは作成されている為_、
二重にインデックスを張る行為には _全く意味がない_。
56 ：NAME IS NULL：05/01/05 17:52:21 ID:???
57 ：NAME IS NULL：05/01/06 06:11:50 ID:???
主キー指定して取得するからピンポンが発生するんだろ。
なぜ、主キー指定して取得してるのに、ピンポンを発生させているのか考えれば、
わかる話だろう。
まともなSQL書けばすむ話だ。
ストアド以前の話だな。
よってインデックスが正しい。
なぜ、主キー指定して取得してるのに、ピンポンを発生させているのか考えれば、
わかる話だろう。
まともなSQL書けばすむ話だ。
ストアド以前の話だな。
よってインデックスが正しい。
58 ：NAME IS NULL：05/01/06 08:33:10 ID:???
59 ：NAME IS NULL：05/01/06 10:24:06 ID:???
>>58
わからないなら黙ってろ。
わからないなら黙ってろ。
60 ：NAME IS NULL：05/01/06 10:52:57 ID:???
>>59
負け犬乙
負け犬乙
61 ：NAME IS NULL：05/01/06 11:30:58 ID:???
62 ：NAME IS NULL：05/01/06 12:00:46 ID:???
>>61
m9（＾Д＾）ﾌﾟｷﾞｬｰ ぜんぜん意味わかってねー。
m9（＾Д＾）ﾌﾟｷﾞｬｰ ぜんぜん意味わかってねー。
63 ：NAME IS NULL：05/01/06 14:04:06 ID:???
＞いまでも主キー指定での取得になっていて…
これと似た台詞を聞いたことがあるけど、念のため調べてみたら
primary key (項目A, 項目B)の構成のテーブルで
項目Bだけで検索してたというのがあったよ。
大昔のRDBのなかには
a) where 項目A = ? and 項目B = ?
b) where 項目B = ? and 項目A = ?
で索引を使ったり使わなかったりしたのもあったけど最近のは大丈夫ですよね？
これと似た台詞を聞いたことがあるけど、念のため調べてみたら
primary key (項目A, 項目B)の構成のテーブルで
項目Bだけで検索してたというのがあったよ。
大昔のRDBのなかには
a) where 項目A = ? and 項目B = ?
b) where 項目B = ? and 項目A = ?
で索引を使ったり使わなかったりしたのもあったけど最近のは大丈夫ですよね？
64 ：NAME IS NULL：05/01/06 15:01:59 ID:???
>>57
想像するに…
・一行ずつ取得ではなく、複数行持ってきてUPDATEはループで回せ。
・UPDATE一発でやれ
のどちらかを言いたいのだと思うけど、それじゃ出来ない処理なんて
いくらでもある。そう言うときの為にストアドがある。
そもそも
「ストアドが存在するDBMSにもかかわらずクライアントでバッチ更新」
なんて仕様が出てくる時点で間違い。
>>63
> 最近のは大丈夫ですよね？
そうでもないよ。
想像するに…
・一行ずつ取得ではなく、複数行持ってきてUPDATEはループで回せ。
・UPDATE一発でやれ
のどちらかを言いたいのだと思うけど、それじゃ出来ない処理なんて
いくらでもある。そう言うときの為にストアドがある。
そもそも
「ストアドが存在するDBMSにもかかわらずクライアントでバッチ更新」
なんて仕様が出てくる時点で間違い。
>>63
> 最近のは大丈夫ですよね？
そうでもないよ。
65 ：NAME IS NULL：05/01/06 15:14:53 ID:???
66 ：NAME IS NULL：05/01/06 17:01:57 ID:???
67 ：NAME IS NULL：05/01/07 18:59:59 ID:???
ストアドでバッチ処理を書き直したまではいいのだけれど、
数件おきにコミットさせるとカーソルがクローズしてエラーになってしまう。
１件分の処理の間に子レコードの処理も入るのでトランザクションは使いた
いのだが全部処理するには総数が大きい。さてどうするべ、週末なのに・・・
数件おきにコミットさせるとカーソルがクローズしてエラーになってしまう。
１件分の処理の間に子レコードの処理も入るのでトランザクションは使いた
いのだが全部処理するには総数が大きい。さてどうするべ、週末なのに・・・
68 ：NAME IS NULL：05/01/07 19:30:04 ID:???
やかん
69 ：NAME IS NULL：05/01/07 19:52:36 ID:???
70 ：NAME IS NULL：05/01/07 19:54:15 ID:???
71 ：NAME IS NULL：05/01/08 00:52:36 ID:/A2kgL9D
そこでインデックスですよ。
72 ：NAME IS NULL：05/01/12 23:38:32 ID:???
73 ：NAME IS NULL：05/01/13 00:41:48 ID:???
確かに>>57って笑えるｗ
74 ：NAME IS NULL：05/01/13 23:21:13 ID:Yo88RG9E
>>70
DB2とかのやり方をまねしちゃだめ。
カーソルループ中にCOMMITする発想はあんましよくない。
途中でこけたら元に戻せなくなる。
そういう場合はロールバックセグメントを大きくとっておくのがOracleのやりかた。
DB2とかのやり方をまねしちゃだめ。
カーソルループ中にCOMMITする発想はあんましよくない。
途中でこけたら元に戻せなくなる。
そういう場合はロールバックセグメントを大きくとっておくのがOracleのやりかた。
75 ：NAME IS NULL：05/01/14 03:07:55 ID:???
えせOracleの香りがぷんぷんする
76 ：NAME IS NULL：05/01/14 07:41:07 ID:???
>>74
最後の一行は要らなかったな
最後の一行は要らなかったな
77 ：NAME IS NULL：05/01/15 23:43:35 ID:???
>>74
そうか？ケースバイケースだろ。
カーソルループの中で一部のデータのみコミットされると整合性がとれ
なくなるなケースはおっしゃる通りだが。
カーソルループの中で一部のデータのみコミットされても整合性がとれ
るケースだってないか。
その場合は、カーソルループの中でコミットしたほうがロックの期間
が短くなるし、いいと思うけど。
ロックの期間を短くしたほうがいいっていうのは、どんなDBでも同じ
じゃねーか。
そうか？ケースバイケースだろ。
カーソルループの中で一部のデータのみコミットされると整合性がとれ
なくなるなケースはおっしゃる通りだが。
カーソルループの中で一部のデータのみコミットされても整合性がとれ
るケースだってないか。
その場合は、カーソルループの中でコミットしたほうがロックの期間
が短くなるし、いいと思うけど。
ロックの期間を短くしたほうがいいっていうのは、どんなDBでも同じ
じゃねーか。
78 ：NAME IS NULL：05/01/16 02:14:22 ID:???
>>77
カーソルループでの更新が途中でこけると、どこまでやったかがわかんないから最初からやり直すことになると思うけど。
このとき、途中までCOMMITしてたらそこまでの更新をもう1回やることになる。
それでも整合性がとれるようなケースってあんましなさそうな気がするけど...
カーソルループでの更新が途中でこけると、どこまでやったかがわかんないから最初からやり直すことになると思うけど。
このとき、途中までCOMMITしてたらそこまでの更新をもう1回やることになる。
それでも整合性がとれるようなケースってあんましなさそうな気がするけど...
79 ：NAME IS NULL：05/01/16 10:18:16 ID:???
80 ：NAME IS NULL：05/01/16 12:25:52 ID:???
そのあたり、セーブポイントでどうにかできないのでしょうか。
81 ：NAME IS NULL：05/01/16 19:27:34 ID:???
そもそもセーブポイントって、どういうものか理解しているのか？
>>78,79
カーソルループの中で整合性が取れるケースって、珍しくはないよ。
いくつか思いつくけどね。
例えば、受注テーブルを基に、物流システムへ渡す出荷指示データ
を作成するバッチ処理とか。
受注テーブルの出荷指示フラグと出荷日を基にカーソルループでまわす
場合。で、ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
テーブル更新、出荷指示テーブル作成とかやってる場合、処理する受注伝票
単位で整合性が取れてれば問題ないというケース。
>管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。
正直、意味が良くわからん。多分、管理が非常にむずかしくなるってのは、
どこまでコミットしたかを把握したいという意味なんだろうけど。
すでにコミットしたデータは、整合性が取れてるわけだから、基本的には気に
する必要はない。プログラムの不具合で、コミットしたデータの信頼性が損なわれている
場合でも、テーブルに更新時のタイムスタンプと最終更新PGMのIDでも持たせて
おけば、調査できるだろ。
基本的にはバグなんだから、それよりロックの期間が長くなるというデメリット
のほうが俺はいやだね。
カーソルループの中で整合性が取れるケースって、珍しくはないよ。
いくつか思いつくけどね。
例えば、受注テーブルを基に、物流システムへ渡す出荷指示データ
を作成するバッチ処理とか。
受注テーブルの出荷指示フラグと出荷日を基にカーソルループでまわす
場合。で、ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
テーブル更新、出荷指示テーブル作成とかやってる場合、処理する受注伝票
単位で整合性が取れてれば問題ないというケース。
>管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。
正直、意味が良くわからん。多分、管理が非常にむずかしくなるってのは、
どこまでコミットしたかを把握したいという意味なんだろうけど。
すでにコミットしたデータは、整合性が取れてるわけだから、基本的には気に
する必要はない。プログラムの不具合で、コミットしたデータの信頼性が損なわれている
場合でも、テーブルに更新時のタイムスタンプと最終更新PGMのIDでも持たせて
おけば、調査できるだろ。
基本的にはバグなんだから、それよりロックの期間が長くなるというデメリット
のほうが俺はいやだね。
83 ：NAME IS NULL：05/01/17 09:39:55 ID:???
>>82
彼らの言っているのは
> ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
> テーブル更新、出荷指示テーブル作成とかやってる場合
この「ループの中」の途中でコミットしてしまうと言うケースを想定して
話をしているんだよ。
「カーソルループ」と言う言葉に捕らわれすぎで話の本質が分かってない。
彼らの言っているのは
> ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
> テーブル更新、出荷指示テーブル作成とかやってる場合
この「ループの中」の途中でコミットしてしまうと言うケースを想定して
話をしているんだよ。
「カーソルループ」と言う言葉に捕らわれすぎで話の本質が分かってない。
84 ：77：05/01/17 10:52:52 ID:1w1sWpKp
>>83
そうなのか？だとすると確かにレアケースだが。
67の質問ってそういう意味じゃねーと思うがな。実際、DB2,MSSQL,
Oracleもデフォルトじゃコミットしたら、カーソルクローズしちゃう
しな。(SQL92の仕様だからだろうけど。）
69の回答も俺とおんなじ理解だろ。
話の本質が分かってないのは、お前のほうじゃねーかって気がするがな。
そうなのか？だとすると確かにレアケースだが。
67の質問ってそういう意味じゃねーと思うがな。実際、DB2,MSSQL,
Oracleもデフォルトじゃコミットしたら、カーソルクローズしちゃう
しな。(SQL92の仕様だからだろうけど。）
69の回答も俺とおんなじ理解だろ。
話の本質が分かってないのは、お前のほうじゃねーかって気がするがな。
85 ：NAME IS NULL：05/01/17 11:13:38 ID:???
86 ：NAME IS NULL：05/01/17 11:15:32 ID:???
訂正
67に対しては70でFA出てる
67に対しては70でFA出てる
87 ：77：05/01/17 12:47:35 ID:1w1sWpKp
>>85
>そこから先の話はトランザクション内でのコミットの是非についてだろ。
そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
整合性を確保できる最小単位であることだ。（原子性、一貫性）
俺が77で言っているのは、カーソルループ1回単位が１トランザクション
の場合と、カーソルループ全体が１トランザクションの場合の話。
>>67に対しては70でFA出てる
やっぱり話の本質が分かってないのは、お前のほうだと思うがな。俺は、
70に対する返答(74)に対して、77で返答してんだから。
どこから、トランザクション内でのコミットの是非についてになったん
だ。
>そこから先の話はトランザクション内でのコミットの是非についてだろ。
そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
整合性を確保できる最小単位であることだ。（原子性、一貫性）
俺が77で言っているのは、カーソルループ1回単位が１トランザクション
の場合と、カーソルループ全体が１トランザクションの場合の話。
>>67に対しては70でFA出てる
やっぱり話の本質が分かってないのは、お前のほうだと思うがな。俺は、
70に対する返答(74)に対して、77で返答してんだから。
どこから、トランザクション内でのコミットの是非についてになったん
だ。
88 ：NAME IS NULL：05/01/17 13:26:16 ID:???
>>88
二段落目読んでも解らないとなるとヤバイ。
二段落目読んでも解らないとなるとヤバイ。
90 ：NAME IS NULL：05/01/17 16:00:24 ID:2hmp7s5X
そもそも同列に語ることがおかしいってスレでいいんだよな。
・ストアド化による性能向上
ミドルウェア及び通信等のコスト減を目的
・インデックスをきちんとすること
データに対するアクセス経路の最適化を目的
・ストアド化による性能向上
ミドルウェア及び通信等のコスト減を目的
・インデックスをきちんとすること
データに対するアクセス経路の最適化を目的
91 ：NAME IS NULL：05/01/17 17:36:33 ID:???
92 ：NAME IS NULL：05/01/18 01:10:45 ID:???
>>90
>>91の言うように、話題が変わってます。
カーソルループで大量更新をする場合の話。
>>87,88
想定している状況がそれぞれ違ってるみたいだから
ちょっとこじれかけてるけど、めずらしくまともな議論
に育ちそうだからマターリいこーぜー。
>>91の言うように、話題が変わってます。
カーソルループで大量更新をする場合の話。
>>87,88
想定している状況がそれぞれ違ってるみたいだから
ちょっとこじれかけてるけど、めずらしくまともな議論
に育ちそうだからマターリいこーぜー。
すごい遅レスだが。
>そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
>整合性を確保できる最小単位であることだ。（原子性、一貫性）
これは、トランザクションは整合性を確保する最小単位だから、
トランザクション内部でのコミットは有り得ないということが
言いたかった。
>そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
>整合性を確保できる最小単位であることだ。（原子性、一貫性）
これは、トランザクションは整合性を確保する最小単位だから、
トランザクション内部でのコミットは有り得ないということが
言いたかった。
94 ：NAME IS NULL：2005/04/05(火) 22:33:18 ID:fPFmefwY
OracleのSPはネーティブコードではなくインタプリタのようです、
ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
ですが予想の百倍ぐらい時間がかかりました。
SPそれ自身の実行速度はVBとたいして変わらない印象です、
サーバに中途半端なCPUを使うとPCでVBのほうが早い可能性も
ありです。
ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
ですが予想の百倍ぐらい時間がかかりました。
SPそれ自身の実行速度はVBとたいして変わらない印象です、
サーバに中途半端なCPUを使うとPCでVBのほうが早い可能性も
ありです。
95 ：NAME IS NULL：2005/04/05(火) 23:12:17 ID:???
>>94
たいていの処理系ではStored ProcedureはP-Codeのような中間言語方式だから
Oracleもそうじゃないかな。一般的にサーバーサイドでCPUを多く使う処理は
避けたほうがいいから問題ないように思う。複雑な処理をしたいならOracle内臓の
JServer VMでJava stored procedureを使うという手もある。こちらはJITでコンパ
イルされるから２回目以降の処理は速い。
たいていの処理系ではStored ProcedureはP-Codeのような中間言語方式だから
Oracleもそうじゃないかな。一般的にサーバーサイドでCPUを多く使う処理は
避けたほうがいいから問題ないように思う。複雑な処理をしたいならOracle内臓の
JServer VMでJava stored procedureを使うという手もある。こちらはJITでコンパ
イルされるから２回目以降の処理は速い。
96 ：NAME IS NULL：2005/04/05(火) 23:35:00 ID:???
97 ：NAME IS NULL：2005/04/06(水) 01:54:36 ID:???
>>94-96
PL/SQLはネイティブコンパイルもできる
PL/SQLはネイティブコンパイルもできる
98 ：NAME IS NULL：2005/04/06(水) 03:50:58 ID:???
>>97
そういえばそんなのがありましたね。Cコンパイラが別に必要だったり、
設定がめんどかったり、SQLなどのDBアクセス部分には効果がなかったり
で結局使いませんでした。
＞ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
こういうのには効果がありそうです。
そういえばそんなのがありましたね。Cコンパイラが別に必要だったり、
設定がめんどかったり、SQLなどのDBアクセス部分には効果がなかったり
で結局使いませんでした。
＞ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
こういうのには効果がありそうです。
99 ：NAME IS NULL：2005/04/06(水) 20:12:09 ID:???
ここが一番ヘビーユーザーが多いみたいだね
教えて欲しいのだが、行レベルロックに対応しているDBはオラクル
以外にありますか？
教えて欲しいのだが、行レベルロックに対応しているDBはオラクル
以外にありますか？
100 ：NAME IS NULL：2005/04/06(水) 20:23:32 ID:???
101 ：NAME IS NULL：2005/04/06(水) 20:24:16 ID:???
>>99
Access2000/2003
Access2000/2003
102 ：NAME IS NULL：2005/04/06(水) 20:45:26 ID:???
103 ：NAME IS NULL：2005/04/06(水) 21:05:03 ID:PM6d5T4G
104 ：NAME IS NULL：2005/04/06(水) 21:18:53 ID:???
>103
あれって、インデックスが無いと
ページになるんじゃなかったけ？
勘違いかな。
あれって、インデックスが無いと
ページになるんじゃなかったけ？
勘違いかな。
105 ：U ◆CZtFsGiu0c ：2005/04/06(水) 21:37:45 ID:???
>>104
「テーブルスキャン」と混同してない?
SQLServerは7.0から行ロックをサポートしてるし、Sybaseは11.9.xから。
DB2は知らんけど、今時行ロックサポートしてない商用RDBMSなんて相手に
されないと思うけど。
「テーブルスキャン」と混同してない?
SQLServerは7.0から行ロックをサポートしてるし、Sybaseは11.9.xから。
DB2は知らんけど、今時行ロックサポートしてない商用RDBMSなんて相手に
されないと思うけど。
106 ：NAME IS NULL：2005/04/06(水) 22:41:20 ID:???
>>99
おまいはここが質問ｽﾚかどうかも解らんのか？
おまいはここが質問ｽﾚかどうかも解らんのか？
107 ：NAME IS NULL：2005/04/08(金) 00:58:03 ID:???
>1 を読む限りここは愚痴スレだね。
108 ：NAME IS NULL：2005/04/09(土) 02:07:58 ID:???
10年ぐらい前なんでよく憶えてないが、DB2も行ロックするよ
109 ：NAME IS NULL：2005/04/09(土) 20:41:32 ID:???
運用担当が行ロックをありがたがるのは理解できるのだが、
開発担当が行ロックじゃなきゃ使えないとか言ってるのを聞くと
それは技術力がないという以前の単なるへたれなだけのような気がする。
開発担当が行ロックじゃなきゃ使えないとか言ってるのを聞くと
それは技術力がないという以前の単なるへたれなだけのような気がする。
110 ：NAME IS NULL：2005/04/09(土) 20:46:11 ID:???
111 ：NAME IS NULL：2005/05/29(日) 22:48:27 ID:GvDeAxP+
>ストアドよりインデックスのほうが速いよ (＜−−スレタイ)
それぞれ、どのようにした速度が改善されるのかを考えたほうがいい
ストアドによる処理速度の向上は以下の２点による。
１．プログラムがサーバーにあるためサーバークライアント間の
回線経由のデータ転送をなくすことによる速度アップである
２．SQLを中間言語に落とすことにより、インタープリタの必要がない
インデックスによる速度改善とは以下
３．ディスクアクセスを少なくする。
ストアドを使うときの注意事項
４．ストアドはＬＡＮ環境だと１．の速度アップは期待できない。低速の
ネットワークならば期待できる。
５．ストアドのプログラムの管理が面倒。デバックしにくいＤＢもある。
結論を言うと、
６．インデックスによる速度アップはすべきである。
（というか、これをしないと普通は、実運用に耐えられない）
７．ストアドによる速度アップはＬＡＮ環境でのＣ／Ｓの場合は
期待できない。低速回線経由のＣ／Ｓならば期待できる。
８．ロジックを共有するという目的ならばストアドの使用は可。
以上かな。
それぞれ、どのようにした速度が改善されるのかを考えたほうがいい
ストアドによる処理速度の向上は以下の２点による。
１．プログラムがサーバーにあるためサーバークライアント間の
回線経由のデータ転送をなくすことによる速度アップである
２．SQLを中間言語に落とすことにより、インタープリタの必要がない
インデックスによる速度改善とは以下
３．ディスクアクセスを少なくする。
ストアドを使うときの注意事項
４．ストアドはＬＡＮ環境だと１．の速度アップは期待できない。低速の
ネットワークならば期待できる。
５．ストアドのプログラムの管理が面倒。デバックしにくいＤＢもある。
結論を言うと、
６．インデックスによる速度アップはすべきである。
（というか、これをしないと普通は、実運用に耐えられない）
７．ストアドによる速度アップはＬＡＮ環境でのＣ／Ｓの場合は
期待できない。低速回線経由のＣ／Ｓならば期待できる。
８．ロジックを共有するという目的ならばストアドの使用は可。
以上かな。
112 ：NAME IS NULL：2005/05/29(日) 23:32:52 ID:???
> 111
あんたが正解。
クエリー投げてカーソル範囲を確定するのに
一番影響するのがインデックスだし、
インデックスをつけても、変わらないのがC/S間の
データ転送速度。（FETCHね）
ストアドなら、ネットワークインフラの性能が
左右するが、クライアントからのちまちました
カーソルFETCHかますより、全レコードを配列変数などで
アウトパラメタとして一括送信したほうが早い場合も
ある。
全て条件付きのケースバイケースだけど、
「クエリを実行してカーソルを確定する」部分と
「カーソルからレコードを取得する」部分の違いは
ちゃんと理解したほうがいいですね。
FETCHしたレコードが大して多くないのに、処理が遅いとかって、
大体クエリの効率が悪く、カーソル処理の場合FETCH − LOOPではなく
その前のクエリ実行が遅かったりする。
そんなときは、いくらストアドにしてもだめ。
SELECT文の実行計画を調べて、その対処としてインデックスを
付与することが明らかであれば、そうすべし。
あんたが正解。
クエリー投げてカーソル範囲を確定するのに
一番影響するのがインデックスだし、
インデックスをつけても、変わらないのがC/S間の
データ転送速度。（FETCHね）
ストアドなら、ネットワークインフラの性能が
左右するが、クライアントからのちまちました
カーソルFETCHかますより、全レコードを配列変数などで
アウトパラメタとして一括送信したほうが早い場合も
ある。
全て条件付きのケースバイケースだけど、
「クエリを実行してカーソルを確定する」部分と
「カーソルからレコードを取得する」部分の違いは
ちゃんと理解したほうがいいですね。
FETCHしたレコードが大して多くないのに、処理が遅いとかって、
大体クエリの効率が悪く、カーソル処理の場合FETCH − LOOPではなく
その前のクエリ実行が遅かったりする。
そんなときは、いくらストアドにしてもだめ。
SELECT文の実行計画を調べて、その対処としてインデックスを
付与することが明らかであれば、そうすべし。
113 ：NAME IS NULL：2005/05/30(月) 01:27:21 ID:???
> ストアドによる速度アップはＬＡＮ環境での C/S の場合は期待できない。
これには反論あり。100Mbps の LAN であってもサーバーカーソルを使うと
著しいパフォーマンス低下をもたらす。参照系だけでファイアーホースを
使うならともかく、サーバーカーソルを使ってフェッチ&アップデートを
繰り返すなんて LAN でもやるべきではない。
>>1 はフェッチ&アップデートの多発で速度低下していると言っているのだろう。
その考えは結構正しい。LAN であってもユーザーの判断・操作を
必要としない一括更新はストアドにすべし。クライアントプロセスで
更新する必要性がなかろう。
これには反論あり。100Mbps の LAN であってもサーバーカーソルを使うと
著しいパフォーマンス低下をもたらす。参照系だけでファイアーホースを
使うならともかく、サーバーカーソルを使ってフェッチ&アップデートを
繰り返すなんて LAN でもやるべきではない。
>>1 はフェッチ&アップデートの多発で速度低下していると言っているのだろう。
その考えは結構正しい。LAN であってもユーザーの判断・操作を
必要としない一括更新はストアドにすべし。クライアントプロセスで
更新する必要性がなかろう。
114 ：NAME IS NULL：2005/05/30(月) 01:30:39 ID:???
ここは「頭の悪そうな発言をする」スレですか？
115 ：NAME IS NULL：2005/05/30(月) 01:37:20 ID:???
>>111
ストアドの利点はもう１つあって、それは静的ＳＱＬ構文であること。
既にコンパイル済みなので、ＳＱＬ文の構文解析の手間が無いので高速。
あと高速化とは関係無いけど、バグが発生した場合はＤＢサーバに対して修正するだけで良い。
Ｃ／Ｓシステムほど、その効果が高い。
ストアドの利点はもう１つあって、それは静的ＳＱＬ構文であること。
既にコンパイル済みなので、ＳＱＬ文の構文解析の手間が無いので高速。
あと高速化とは関係無いけど、バグが発生した場合はＤＢサーバに対して修正するだけで良い。
Ｃ／Ｓシステムほど、その効果が高い。
116 ：NAME IS NULL：2005/05/30(月) 02:15:18 ID:???
117 ：NAME IS NULL：2005/05/30(月) 13:43:06 ID:???
>>114
いいえ、的外れなことをそれっぽく言ってみようとするスレです
いいえ、的外れなことをそれっぽく言ってみようとするスレです
118 ：NAME IS NULL：2005/05/30(月) 15:22:59 ID:RbWMGJ3o
>>114, 116, 117
君たちの見解を知りたいものだ
君たちの見解を知りたいものだ
119 ：NAME IS NULL：2005/05/30(月) 16:24:32 ID:???
クソスレの有効利用でいいことじゃないか。何を粘着してるんだか。
> 113
DBサーバ上のローカルアクセスならLAN性能は関係ないぞ。
サーバマシン単体の性能なら話はわかるが。
DBサーバ上のローカルアクセスならLAN性能は関係ないぞ。
サーバマシン単体の性能なら話はわかるが。
121 ：NAME IS NULL：2005/05/31(火) 00:08:44 ID:???
>>120
いや同一ホスト内であってもサーバーカーソルを別プロセスから
動かすってのは、かなりの高コスト処理なのよ。
ADO なんかで MoveNext とかするでしょ。サーバーカーソルの場合
そのたびにサーバーカーソルを動かすためのストアドとかが裏で呼ばれるわけ。
いや同一ホスト内であってもサーバーカーソルを別プロセスから
動かすってのは、かなりの高コスト処理なのよ。
ADO なんかで MoveNext とかするでしょ。サーバーカーソルの場合
そのたびにサーバーカーソルを動かすためのストアドとかが裏で呼ばれるわけ。
122 ：NAME IS NULL：2005/05/31(火) 01:00:55 ID:???
だから、FETCHもサーバ（プロセス）でやって、データを一括で返せば？
SQL Server のストアドは詳しくないが、アウトパラメタで配列
返すことはできたっけ？
SQL Server のストアドは詳しくないが、アウトパラメタで配列
返すことはできたっけ？
123 ：NAME IS NULL：2005/05/31(火) 10:56:31 ID:Pwnlm8uV
124 ：NAME IS NULL：2005/05/31(火) 18:14:44 ID:???
125 ：NAME IS NULL：2005/07/25(月) 16:44:44 ID:cf5vlPiQ
似たような速度の話を一つ。
３０００件（５フィールド）のデータがあるとして、
１．ストアド内でカーソルで回して使用
２．最初に配列に取り込みカウンタで回して使用
上の数字は、適当なものだけど、こゆ場合は、どっちが速いの？
カーソルって１レコード分のデータのみメモリにあるのかな？
ＤＢアクセスしてるとしたら、２．のが速そうなんだけど。
だれか分かる人〜
３０００件（５フィールド）のデータがあるとして、
１．ストアド内でカーソルで回して使用
２．最初に配列に取り込みカウンタで回して使用
上の数字は、適当なものだけど、こゆ場合は、どっちが速いの？
カーソルって１レコード分のデータのみメモリにあるのかな？
ＤＢアクセスしてるとしたら、２．のが速そうなんだけど。
だれか分かる人〜
126 ：NAME IS NULL：2005/08/05(金) 16:26:31 ID:???
配列にいれると２度手間だからどう考えても遅いよ。
データベースの種類にもよるけど、メモリにあるのはキャッシュされた複数レコード。
SQLをコンパイルしたコードとインデックス位置を保持してるのがカーソル。
読み込みはキャッシュか物理記憶からその情報を元に呼ばれる。
データベースの種類にもよるけど、メモリにあるのはキャッシュされた複数レコード。
SQLをコンパイルしたコードとインデックス位置を保持してるのがカーソル。
読み込みはキャッシュか物理記憶からその情報を元に呼ばれる。
127 ：NAME IS NULL：2005/10/15(土) 20:13:42 ID:QwLPLcWX
ここ意見バラバラなのな
128 ：NAME IS NULL：2005/10/15(土) 22:04:11 ID:???
129 ：NAME IS NULL：2005/10/17(月) 02:06:04 ID:???
インデックスよりトリガのほうがはやいよ
130 ：NAME IS NULL：2005/10/17(月) 19:48:53 ID:M18TRkZF
ストアドより自前DBの方が速いよ
131 ：NAME IS NULL：2005/10/17(月) 22:02:24 ID:???
自前DBよりエイトマンのほうがはやいよ
132 ：NAME IS NULL：2005/10/18(火) 09:19:25 ID:???
お前より俺の方が早漏だよ
133 ：側近中の側近 ◆0351148456 ：2006/04/22(土) 22:27:38 ID:???
(っ´▽｀)っ
っていうか、要するに
インデックスとストアドの両方を採用すればいいんじゃね？
って言えばいいんじゃね？
と半年振りに書き込んだ私に誰か拍手してくれよん☆
っていうか、要するに
インデックスとストアドの両方を採用すればいいんじゃね？
って言えばいいんじゃね？
と半年振りに書き込んだ私に誰か拍手してくれよん☆
135 ：側近中の側近 ◆0351148456 ：2006/04/23(日) 08:07:05 ID:???
136 ：NAME IS NULL：2006/05/03(水) 21:35:45 ID:???
>「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
> 言ってるんだよ。
この台詞、精神論を前面に押し出す現場でよく聞くな。
> 言ってるんだよ。
この台詞、精神論を前面に押し出す現場でよく聞くな。
137 ：NAME IS NULL：2006/06/05(月) 20:52:04 ID:???
その言葉自体には問題ないだろう。
むしろベンチも取らんで決め付ける方が恐ろしい。
結果出てるのに「何かの間違いなんだよ。
こっちの方が早くなんなきゃおかしいんだ！」
とゴリ押しされるのが最悪のパターン。
コードの最適化とかでよく見かける光景。
むしろベンチも取らんで決め付ける方が恐ろしい。
結果出てるのに「何かの間違いなんだよ。
こっちの方が早くなんなきゃおかしいんだ！」
とゴリ押しされるのが最悪のパターン。
コードの最適化とかでよく見かける光景。
138 ：NAME IS NULL：2006/07/11(火) 21:43:45 ID:5xEL92un
昭和年月米潜水艦放魚雷本命中５本不発小破う幸運艦安川孝雄城本高輝読売孝子用紙梱包後昭和年月日北方海域米潜水艦雷撃受魚雷中沈没案現在駐輪場積極的
139 ：NAME IS NULL：2007/01/27(土) 07:26:59 ID:???
140 ：NAME IS NULL：2007/01/28(日) 23:32:31 ID:???
大抵は「ココまで作っちゃったんだから今更修正できません」と言って聞かないような
バカが書いたクソみたいなコードを書き直させると問題解決する。
（そしてストアドかインデックスかなんてどーでも良くなる）
バカが書いたクソみたいなコードを書き直させると問題解決する。
（そしてストアドかインデックスかなんてどーでも良くなる）
141 ：NAME IS NULL：2007/07/16(月) 16:13:22 ID:???
ストアドよりインデックスよりマシンスペック上げた方が速いよ
142 ：NAME IS NULL：2007/07/17(火) 20:06:40 ID:???
ユーザが必要な内容を全部記憶したほうが速いよ
143 ：NAME IS NULL：2007/08/04(土) 13:15:04 ID:khSU9cys
>>139
御堂岡の知人クレーマー三浦秀之
御堂岡の知人クレーマー三浦秀之
144 ：NAME IS NULL：2007/08/18(土) 14:06:49 ID:???
いまOTN http://otn.oracle.co.jp/ 見に行ったら、
メニューのドロップダウンリストが広告のFlashの下にもぐり込んで見えねえ。
メニューのドロップダウンリストが広告のFlashの下にもぐり込んで見えねえ。
145 ：NAME IS NULL：2007/08/19(日) 01:13:00 ID:???
結局、結果は聞けないんだろうか...
んもしかして上司が勝ったんじゃねぇの？
んもしかして上司が勝ったんじゃねぇの？
146 ：NAME IS NULL：2008/02/08(金) 23:00:34 ID:5lKQqYPb
かなり古い発言引っ張り出してなんなんだが、
>>63の
>primary key (項目A, 項目B)の構成のテーブルで
>項目Bだけで検索してたというのがあったよ。
って、この場合、項目Bのみのインデックスがあったほうが性能が
向上するというのは分かるが、主キーインデックス（項目Aと項目Bの複合インデックス）も
まったく役に立たないってわけではないよね？
俺なんか勘違いしてる？
>>63の
>primary key (項目A, 項目B)の構成のテーブルで
>項目Bだけで検索してたというのがあったよ。
って、この場合、項目Bのみのインデックスがあったほうが性能が
向上するというのは分かるが、主キーインデックス（項目Aと項目Bの複合インデックス）も
まったく役に立たないってわけではないよね？
俺なんか勘違いしてる？
147 ：NAME IS NULL：2008/02/09(土) 01:30:49 ID:???
>>146
それで唯一索引が使われる可能性があるとすると
SELECTやWHEREで項目Aと項目Bしか使わないパターン。
データ部を全件スキャンするより索引を全件スキャンしたほうが、
物理的に読み込むボリュームが少なくて済む。
例） SELECT 項目A, 項目B FROM ... WHERE 項目B = ?
それで唯一索引が使われる可能性があるとすると
SELECTやWHEREで項目Aと項目Bしか使わないパターン。
データ部を全件スキャンするより索引を全件スキャンしたほうが、
物理的に読み込むボリュームが少なくて済む。
例） SELECT 項目A, 項目B FROM ... WHERE 項目B = ?
148 ：NAME IS NULL：2008/02/09(土) 23:30:07 ID:hcQ04snf
では、項目Bでソートして読み出すときは？
主キーインデックスって役に立ってる？
主キーインデックスって役に立ってる？
149 ：NAME IS NULL：2008/02/10(日) 05:41:25 ID:???
ぜんぜん
150 ：NAME IS NULL：2008/02/10(日) 14:07:29 ID:o71MNKp9
マジで！？
ショック・・・・・・
ショック・・・・・・
151 ：NAME IS NULL：2008/06/05(木) 14:39:40 ID:OmaPyoR8
かなりショック
152 ：NAME IS NULL：2008/06/07(土) 10:48:14 ID:???
手持ちのDB2だとINDEX使って少しでも実行コスト下げる努力してるけど。
RDBMSによって動作は違うとｵﾓ
RDBMSによって動作は違うとｵﾓ
153 ：NAME IS NULL：2008/06/11(水) 11:55:35 ID:???
パフォーマンスあげるために両方やっとけばいいんじゃね？
で終わりだろ
で終わりだろ
154 ：NAME IS NULL：2008/06/24(火) 17:11:38 ID:???
>>1 の上司が、
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」
と言ってるんだから、
「そうですか、じゃあ、お願いします。」と進言して放置。
少ししてから、ニヤニヤしながら、
「どうでしたか？速くなりました？」と聞きに行くのが正解。
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」
と言ってるんだから、
「そうですか、じゃあ、お願いします。」と進言して放置。
少ししてから、ニヤニヤしながら、
「どうでしたか？速くなりました？」と聞きに行くのが正解。
155 ：NAME IS NULL：2008/07/25(金) 02:08:34 ID:pIJlJ9Ry
インデックスの無い検索をループで繰り返すストアドは遅い。
インデックスの知識が無いやつがストアド書くなって思う。
あと数値を集計して表示の加工する際に同じことができる場合なら
たいていJOINよりUNION ALLの方が速い。これも理由はインデックス。
インデックスの知識が無いやつがストアド書くなって思う。
あと数値を集計して表示の加工する際に同じことができる場合なら
たいていJOINよりUNION ALLの方が速い。これも理由はインデックス。
156 ：NAME IS NULL：2008/07/26(土) 02:39:06 ID:???
そんな単純な話じゃねーよｗ
インデックスは付けたって使われるとは限らない。
使われないインデックスは、データの無駄でしかない。
また、インデックスを使ったからといって早くなるとは限らない。
どういうときにインデックスが使われて、効果があるかを熟知した上で、
インデックスがちゃんと使われるような、SQL（ストアド含む）を書く。
SQL（ストアド）ってのは迷路のようなものだよ。
普通に進めば長く時間がかかる。インデックスは、その迷路に
壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
全体を見て考えないといけない。
SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。
インデックスは付けたって使われるとは限らない。
使われないインデックスは、データの無駄でしかない。
また、インデックスを使ったからといって早くなるとは限らない。
どういうときにインデックスが使われて、効果があるかを熟知した上で、
インデックスがちゃんと使われるような、SQL（ストアド含む）を書く。
SQL（ストアド）ってのは迷路のようなものだよ。
普通に進めば長く時間がかかる。インデックスは、その迷路に
壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
全体を見て考えないといけない。
SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。
157 ：NAME IS NULL：2008/07/27(日) 01:00:22 ID:???
迷路ってほど難解でもないと思うが。
つか、普通に考えればストアドとインデックスとどっちか速いかなんて
無意味な議論しないとｵﾓ
つか、普通に考えればストアドとインデックスとどっちか速いかなんて
無意味な議論しないとｵﾓ
158 ：NAME IS NULL：2008/07/27(日) 11:58:38 ID:???
煙突とダイヤモンドでどちらが高いかという命題に近いな
159 ：NAME IS NULL：2008/07/30(水) 21:27:38 ID:???
データの分布が変わったらインデックスが有効じゃなくなるとかあるだろ。
常に正しい答えなんてねーよ。
常に正しい答えなんてねーよ。
160 ：NAME IS NULL：2008/11/03(月) 08:38:51 ID:???
, -‐ ' ´￣￣ ｀ヽ、
／ ｀ ー- ､
／ }
/ __,. ‐ﾍ
/ ｆ＿＿, -‐ ' ´:.:.:.:.:.:.:.:.:|
/ !:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:}
| ｉ::.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:, ＜＼
| |:.:.:.:.＿_ ,:: -‐: !｢／`ｉ:.!ヽ＞
| √: : : ::ィ! ⌒ｉﾊ: :ﾘ xぇｖ!:!: }
| イ: : : : :/ﾚ斗z- Ｖ ﾄﾘ /リV
| ｲｲ: :.ｲ/ / んﾊ ﾋ! {
∧ ｉ |イ: | ヽ v少 ' ! ストアドよりインデックスの方が
/ ﾑﾍ: : | ､､ __,. 人 速いんだよ
/ ／ /: ﾊ !: |、 ｢ ノ, ｲ !
|_ ／ /: !: | |: :!､ ＞ ､ ィ! :.| / _＿__
/ /: :/!: ﾄﾍ: '!￣.ソ介トヽ: :|／/ / / ＼
/ /: //:ノ:::::|: !ﾆ ノ|::|C} |: :| (つ ｉ / ,ﾉ
/ /:: 彡へ::::::|: |:::＼イ::フ^|: :| `７'ｰ-イ 〜 ♪
/ ／:.∠ /〇}: |＜:::>イ::! !: |.√〈 ,ﾊ
/ イ:.:∠二二.ﾒ､ / |: |`''く:::::|＼! |: |::| ＼/ ! ／)
/ / |:// 厶ノ |: | ∨＿ﾊ.|: !∧ ＼| ／／
/ ! |:/ む' |: | ＼_ソ|: |:::::＼ |∠∠ 、
/ | ､ |:ﾘ |:::!::::| :|＼:::::＼／ ー-- }
/ | ＼ 从 |::::!:::!从 ＞r' ､ ヽ.ﾉ
∧ ﾄ､ ー―へ |::/リ ／::| | rくソ
/::::＼ | ヽ ヽ /:/ ／::::::::| |ー‐' |
＼::::::::＼ | | レ'⌒￣ |:::::::::| | !
／ ｀ ー- ､
／ }
/ __,. ‐ﾍ
/ ｆ＿＿, -‐ ' ´:.:.:.:.:.:.:.:.:|
/ !:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:}
| ｉ::.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:, ＜＼
| |:.:.:.:.＿_ ,:: -‐: !｢／`ｉ:.!ヽ＞
| √: : : ::ィ! ⌒ｉﾊ: :ﾘ xぇｖ!:!: }
| イ: : : : :/ﾚ斗z- Ｖ ﾄﾘ /リV
| ｲｲ: :.ｲ/ / んﾊ ﾋ! {
∧ ｉ |イ: | ヽ v少 ' ! ストアドよりインデックスの方が
/ ﾑﾍ: : | ､､ __,. 人 速いんだよ
/ ／ /: ﾊ !: |、 ｢ ノ, ｲ !
|_ ／ /: !: | |: :!､ ＞ ､ ィ! :.| / _＿__
/ /: :/!: ﾄﾍ: '!￣.ソ介トヽ: :|／/ / / ＼
/ /: //:ノ:::::|: !ﾆ ノ|::|C} |: :| (つ ｉ / ,ﾉ
/ /:: 彡へ::::::|: |:::＼イ::フ^|: :| `７'ｰ-イ 〜 ♪
/ ／:.∠ /〇}: |＜:::>イ::! !: |.√〈 ,ﾊ
/ イ:.:∠二二.ﾒ､ / |: |`''く:::::|＼! |: |::| ＼/ ! ／)
/ / |:// 厶ノ |: | ∨＿ﾊ.|: !∧ ＼| ／／
/ ! |:/ む' |: | ＼_ソ|: |:::::＼ |∠∠ 、
/ | ､ |:ﾘ |:::!::::| :|＼:::::＼／ ー-- }
/ | ＼ 从 |::::!:::!从 ＞r' ､ ヽ.ﾉ
∧ ﾄ､ ー―へ |::/リ ／::| | rくソ
/::::＼ | ヽ ヽ /:/ ／::::::::| |ー‐' |
＼::::::::＼ | | レ'⌒￣ |:::::::::| | !
161 ：NAME IS NULL：2008/11/14(金) 23:44:11 ID:???
drop index に罪悪感を感じるようになるとは思わなかった
162 ：NAME IS NULL：2009/07/21(火) 03:34:29 ID:9pmi0kw9
>>156
どっかのＩＴコンサルを名乗る連中みたいな発言だな。たとえ話や抽象論だけで、
要は何をすればいいのか結局現場まかせみたいな。
>インデックスは付けたって使われるとは限らない。
インデックスって、使う/使わないの二択しかないんだから当たり前の話。
>使われないインデックスは、データの無駄でしかない。
正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
設計も珍しいですが。
>また、インデックスを使ったからといって早くなるとは限らない。
これまた正論。帳票など大量のレコードを結合するときは、インデックスを
使うよりもハッシュジョインのほうが早いですからね。
>どういうときにインデックスが使われて、効果があるかを熟知した上で、
>インデックスがちゃんと使われるような、SQL（ストアド含む）を書く。
こういう部分がプログラマの腕の見せ所でもあるんだろうが、実際はそんな
優秀な人間ばっか集めれるわけじゃあるまいし。びっくりするぐらい雑な
ＳＱＬを書くベテランが大勢いるのが現実なわけで。
>SQL（ストアド）ってのは迷路のようなものだよ。
>普通に進めば長く時間がかかる。インデックスは、その迷路に
>壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
>全体を見て考えないといけない。
わかったような、わからないような、見事に煙に巻く美文だな。
翻訳すると、「ＳＱＬで全件検索すると遅いから、インデックスというミニ
テーブルを参照してデータを検索する機能を使うと、あたかも本の目次を
見て目的のページを開くかのごとく素早く検索できます」ということ？
>SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
>どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。
能書きはいいから両方速くしてください、でＦＡ？
>>154
似たようなことをやった記憶がある。ＳＱＬの話じゃないけどね。
で、予想どおりトンチンカンなものが出来上がってた。
さらに恐ろしいのは、それが成果物として存在感を出して、後続作業はこれと
矛盾しないようにしなければいけないという制約ができたこと。
どっかのＩＴコンサルを名乗る連中みたいな発言だな。たとえ話や抽象論だけで、
要は何をすればいいのか結局現場まかせみたいな。
>インデックスは付けたって使われるとは限らない。
インデックスって、使う/使わないの二択しかないんだから当たり前の話。
>使われないインデックスは、データの無駄でしかない。
正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
設計も珍しいですが。
>また、インデックスを使ったからといって早くなるとは限らない。
これまた正論。帳票など大量のレコードを結合するときは、インデックスを
使うよりもハッシュジョインのほうが早いですからね。
>どういうときにインデックスが使われて、効果があるかを熟知した上で、
>インデックスがちゃんと使われるような、SQL（ストアド含む）を書く。
こういう部分がプログラマの腕の見せ所でもあるんだろうが、実際はそんな
優秀な人間ばっか集めれるわけじゃあるまいし。びっくりするぐらい雑な
ＳＱＬを書くベテランが大勢いるのが現実なわけで。
>SQL（ストアド）ってのは迷路のようなものだよ。
>普通に進めば長く時間がかかる。インデックスは、その迷路に
>壁を一つか二つかあけることができる。どこに壁をあけ、どういうルートを通るか
>全体を見て考えないといけない。
わかったような、わからないような、見事に煙に巻く美文だな。
翻訳すると、「ＳＱＬで全件検索すると遅いから、インデックスというミニ
テーブルを参照してデータを検索する機能を使うと、あたかも本の目次を
見て目的のページを開くかのごとく素早く検索できます」ということ？
>SQLとストアドもな。クライアントとサーバーのどちらでどういう処理が動いて
>どれだけのデータが転送されるかってのを考えないと、どちらが速いかなんて答えは出ない。
能書きはいいから両方速くしてください、でＦＡ？
>>154
似たようなことをやった記憶がある。ＳＱＬの話じゃないけどね。
で、予想どおりトンチンカンなものが出来上がってた。
さらに恐ろしいのは、それが成果物として存在感を出して、後続作業はこれと
矛盾しないようにしなければいけないという制約ができたこと。
163 ：NAME IS NULL：2009/07/22(水) 03:06:00 ID:???
>>156
>使われないインデックスは、データの無駄でしかない
>>162
>正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
>設計も珍しいですが。
容量よりも更新コストを気にするだろ、普通・・・
>使われないインデックスは、データの無駄でしかない
>>162
>正論です。とはいえ、インデックス容量をケチるほどかつかつのハードウェア
>設計も珍しいですが。
容量よりも更新コストを気にするだろ、普通・・・
164 ：NAME IS NULL：2009/07/23(木) 01:24:08 ID:DfQXlsWj
集合操作をまったく理解していない
コボラーが書いたような無駄に長いストアドは勘弁してほしいな。
コボラーが書いたような無駄に長いストアドは勘弁してほしいな。
165 ：NAME IS NULL：2009/07/23(木) 21:41:01 ID:???
SQLを書いてからインデックスを張れば無問題。
いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。
いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。
166 ：NAME IS NULL：2009/07/24(金) 00:33:08 ID:W2V4yxbD
>>165
>SQLを書いてからインデックスを張れば無問題。
SQLを書く前の、テーブル設計する時点でどこにインデックスが必要か考えとくもんだろ？
ついでに言えば、インデックスを張ると更新が遅くなることは知ってるよな？
>いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。
最近のオプティマイザは賢くなって最適な実行計画をたてるらしいが、それでも
インデックスをどこに張るかアドバイスまでしてくれるのは初耳だな。
ちなみに、オプティマイザって何をする機能なのかは知ってるよな？
>SQLを書いてからインデックスを張れば無問題。
SQLを書く前の、テーブル設計する時点でどこにインデックスが必要か考えとくもんだろ？
ついでに言えば、インデックスを張ると更新が遅くなることは知ってるよな？
>いまどきオプティマイザがどこにインデックス張ればいいのか教えてくれる。
最近のオプティマイザは賢くなって最適な実行計画をたてるらしいが、それでも
インデックスをどこに張るかアドバイスまでしてくれるのは初耳だな。
ちなみに、オプティマイザって何をする機能なのかは知ってるよな？
167 ：NAME IS NULL：2009/07/24(金) 10:32:38 ID:lZumjjk/
168 ：NAME IS NULL：2009/08/22(土) 11:32:22 ID:/H1vAtQw
そもそもストアドもインデックスも必要だから存在するんだよ。
正しくテーブル設計した上で、両方とも適切に使わないと、
実用的なシステムは作れない。
正しくテーブル設計した上で、両方とも適切に使わないと、
実用的なシステムは作れない。
169 ：NAME IS NULL：2009/09/02(水) 00:02:05 ID:???
すれ違いで申し訳ありませんが、
主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
どちらが早いのでしょうか。
お分かりになられる方が居られましたらご教授よろしくお願いいたします。
主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
どちらが早いのでしょうか。
お分かりになられる方が居られましたらご教授よろしくお願いいたします。
170 ：NAME IS NULL：2009/09/02(水) 03:29:46 ID:???
それはDBに依存するな
171 ：NAME IS NULL：2009/09/03(木) 10:40:06 ID:???
172 ：NAME IS NULL：2009/09/04(金) 06:09:50 ID:???
173 ：NAME IS NULL：2009/10/29(木) 11:12:53 ID:BZMEXbd0
岡田外務大臣ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
http://qb5.2ch.net/test/read.cgi/saku2ch/1256630318/1
早く記念カキコしないと埋まっちゃうｗｗｗ
174 ：NAME IS NULL：2009/12/15(火) 22:24:09 ID:???
初心者なのでよくわからないのですが、ストアドでインデックス使ったらいいんじゃないの？？？
一度やらせてみてください！
176 ：NAME IS NULL：2009/12/16(水) 12:38:11 ID:???
昨今ストアドを使う意味は、どっちかっていうとセキュロティ強化だろ。
177 ：NAME IS NULL：2009/12/17(木) 15:20:07 ID:???
178 ：NAME IS NULL：2011/02/16(水) 02:02:13 ID:???
>>169
>すれ違いで申し訳ありませんが、
>主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
>どちらが早いのでしょうか。
>お分かりになられる方が居られましたらご教授よろしくお願いいたします。
主キーとインデックスが「全く同じ状況で」全く同じ項目に張られている場合、ということを具体的に説明してください。
主キーとは論理的な概念でインデックスとは通常物理的な概念です。なので比較はできません。
主キーインデックスと主キーでないインデックスが同じ状況で張られるという事を、すなわち「主キーの代わりに一意キーを張る」ということを意味している事と解釈すると、主キーの方が速いです。
（そうでない実装があったら教えてください。）
但し、その場合、全く同じ状況ではありません。理由は上に書いた通りです。（実装が異なります）
>すれ違いで申し訳ありませんが、
>主キーとインデックスは、全く同じ状況で全く同じ項目に張られている場合(かつ、主キーもしくはインデックスのみの指定で検索された場合)
>どちらが早いのでしょうか。
>お分かりになられる方が居られましたらご教授よろしくお願いいたします。
主キーとインデックスが「全く同じ状況で」全く同じ項目に張られている場合、ということを具体的に説明してください。
主キーとは論理的な概念でインデックスとは通常物理的な概念です。なので比較はできません。
主キーインデックスと主キーでないインデックスが同じ状況で張られるという事を、すなわち「主キーの代わりに一意キーを張る」ということを意味している事と解釈すると、主キーの方が速いです。
（そうでない実装があったら教えてください。）
但し、その場合、全く同じ状況ではありません。理由は上に書いた通りです。（実装が異なります）
179 ：電脳プリオン 忍法帖【Lv=40,xxxPT】(1+0：8) 【36.7m】 ：2013/02/03(日) 18:08:40.22 ID:??? BE:152028353-PLT(12080)
ストアドって何よ？
180 ：NAME IS NULL：2013/04/24(水) 18:26:03.20 ID:tyOf/uG0
保守
プラズマで解決