5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ストアドよりインデックスのほうが速いよ

1 :NAME IS NULL:04/09/02 23:11 ID:???
なんかね、データベースからデータを取得して VB で簡単な加工して、
書き戻すっていう更新処理があったのよ。当然、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:???
なんだか言っていることが面白いよね。
本当雑談だよ。

入社1年目の初心者でしょ。

そのあとの話の展開がどうなったのか教えてちょ。


6 :NAME IS NULL:04/09/10 23:52:23 ID:???
>>1にはそのピンポン多発で非常に遅いアプリをどうにかできるだけの
VBやネットワーク、OS辺りの幅広い知識を身につける必要があるという事を
認識してほしい。

7 :NAME IS NULL:04/09/11 03:47:27 ID:???
>>1
逆にストアドプロシージャでは解決する見込みはないと思うけど、解決すると
判断したその根拠は何だろう。
詳細が分からないから断言は難しいけど、やっぱりインデックスが重要だと
思うなぁ。経験的に。

8 :NAME IS NULL:04/09/11 08:05:18 ID:???
…まあ見てから言えよ。な?

>>1の上司は熊先生に似たナイスガイ(ウラヤマスィ

9 :NAME IS NULL:04/09/11 15:25:04 ID:???
こんな感じか? たとえば、半角全角混在の文字項目を全角に統一する。
(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:???
>>7
プロシジャで処理することと
インデックスを張ることは
背反しません。
>経験的に。
無知なまま経験を積んでも実になりませんよ。

12 :NAME IS NULL:04/10/24 01:21:41 ID:???
>1

ミドルウェアの記述がないので、Java環境での話をすると
以前調べた時、NWとミドルを含めたオーバーヘッドは1,2msだった。
数万件単位で大量件数を処理するならSP化は有効だけど
オンライン系で遅いなら他にボトルネックがあると思われる。

もしかして、毎回コネクション張りにいっているという
オチじゃないだろうな・・

ちなみに、更新系はC/S環境でもSPに匹敵する性能がでるよ。
参照系は、SPには勝てんが。。

13 :NAME IS NULL:04/11/14 19:15:55 ID:4kWmAqHu
質問:
3層c/sでアプリサーバーとDBサーバーが同じノード上にある場合はストアド使わなくても
パフォーマンス出るんでしょうか?

14 :NAME IS NULL:04/11/14 19:55:23 ID:cp9oa1wi
http://jbbs.livedoor.jp/sports/352/

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
まぁそんなにムキるな。どーせ釣りだろ(w

17 :NAME IS NULL:04/11/15 15:01:28 ID:???
どうしようって言うくらい馬鹿ばかりだなこのスレ。

>>5-7あたりがネタじゃなくて真面目に言ってるとしたら、日本のIT技術者が
素人ばかりというのもあながち間違ってない。


18 :NAME IS NULL:04/11/15 18:56:55 ID:???
>>1の文章が理解できません・・・
どれが1の発言で、どれが上司の発言なんでしょうか?



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。

22 :a:04/11/27 09:59:43 ID:SLvZscV9
何回もSQLを発行してない?最近みたプログラムで、カーソルのル
ープ使ってその中でさらに問い合わせを発行して、何万回もSQLを
発行するようなプログラムを見た。
結局、テーブルを結合して一回で問い合わせが完了するようにSQL
を書き直したら、嘘みたいに早くなったよ。工夫してみれば?

23 :NAME IS NULL:04/11/28 19:39:51 ID:???
22> ちみはまだ経験が足りん

24 :NAME IS NULL:04/11/30 02:20:37 ID:???
>>23
なんで?1の書き込みには詳細が書いてないから、
22の意見が出てもおかしくないような気が。

25 :NAME IS NULL:04/11/30 05:13:06 ID:???
結合するより、何回もSQL発行した場合も早いこともあるわけで 一概には言えないと?>>23

26 :NAME IS NULL:04/11/30 12:15:45 ID:???
>>25
結合するだけで出来るような問い合わせが
自力ループより遅くなるとは考えにくいが。
-- 副問い合わせを含む問い合わせが
-- 自力ループより遅くなる事はある

27 :NAME IS NULL:04/12/01 01:16:29 ID:???
今更ながら、1の書き込みを読み直してみるとw

問題点を通信のオーバーヘッドではないか?と考えているので
>>22さんの意見は、良いところをついているのではないかな。

昔の話だけど実際にそのようなケースを生産性・品質向上
取り組みの副作用として見たことがあるよ。

その時は共通チームが業務共通系の処理を共通関数として
提供してしまった?ため、それに関わるようなマスタテーブルは
そんな処理になってしまった。

最近はマシンも速いから一見遅くはないけど、負荷の高い処理って
なかなか問題が表面化しないで、地雷みたいに埋まってるんだよねぇ。。

28 :NAME IS NULL:04/12/01 11:07:14 ID:???
>>27
問題とするところがまったく違うんじゃないか?

>>1 の上司が莫迦だって話だろう?スレタイからしても。

29 :NAME IS NULL:04/12/24 16:02:31 ID:tUfbN2jS
>>28
たしかに問題とする次元が違ってると思う。

 |非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか?」って
 |上司に言ったわけです。勇気をふりしぼって。

インデックス…問い合わせ効率を向上させるためのもの(ツメ見出し)
ストアド…SQL文をプリコンパイル済みにして通常のSQLが問い合わせ前に行う
 プリコンパイル作業等に掛かる時間的ロスを軽減する

でなかったか?


バッチ処理するのにインデックスあったら効率悪いので
インデックスをdrop

バッチ

インデックスを(再びCreate)

(シェアードテーブル化できないならSELECT文でキャッシュに)

だろう…


もっと詳しい人どうぞ。(w

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捨てれ
話はそれからだ

34 :NAME IS NULL:04/12/25 11:59:43 ID:???
また、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無しなどの大域処理をしてしまうと1命令を1トランザクションで実行しよう
とするから、ロックは広い範囲にかかりまくるし、オラクルだとロールバックセ
グメントに書き出しまくる。そのせいか処理が妙に重たい。
ストアドでカーソル使ってwhere current ofで処理しても、ループで内でupdateや
insert命令を実行してもロックやRBSがらみのリソースを消費してる感じです。
仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
それをキーにして数十件ずつコミットしながら更新かけてゆく方法をとったら
俄然処理が速くなりました。
こういうケースでは一般的にはどうするのがいいのでしょうか?

38 :NAME IS NULL:04/12/25 15:33:56 ID:???
>仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
これをDB内で済ませろ

39 :NAME IS NULL:04/12/25 15:58:31 ID:???
>29
プリコンパイル(静的SQL)とストアドプロシジャは全く別のものだよ。

40 :NAME IS NULL:04/12/25 16:23:54 ID:???
>>38
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だと普通の手続き型言語に似てるからとっつきは良いけど
使い方は要注意だ。非効率な変な書き方もできてしまうからな。

43 :NAME IS NULL:04/12/25 19:54:30 ID:???
>>36
OS かお前のマシンがしょぼいんじゃねーか ?

あるいは、バグバグしてるコンポーネント使いまくりとかな。

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
>>36
自分の技術の無さをVBのせいにするな


46 :NAME IS NULL:04/12/26 17:35:00 ID:???
そもそもバッチ更新なのにコンポーネントは全く関係なし。
アプリに負担をかけることすら間違い。

それとクライアントに一端処理を移すとのことだけれども
ストアドやインデックス云々より、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』 文にした方がベターだな


52 :NAME IS NULL:05/01/05 08:57:34 ID:???
>>51
論点がずれてる。
上司が言ったのは、すばやく目標を達成するにはって話だ。
よって、インデックスで良いんだよ。
それを>>1が高速化技法の話に摩り替えた。
よく読め。

53 :NAME IS NULL:05/01/05 12:16:39 ID:???
>>52
>よく読め。

>>1
>「いまでも主キー指定での取得になっていて…」

莫迦麦価

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 間のピンポン多発で非常に遅いでやんす。
が解消される事が期待できる。

一方、主キーには _既にインデックスは作成されている為_、
二重にインデックスを張る行為には _全く意味がない_。

56 :NAME IS NULL:05/01/05 17:52:21 ID:???
>>55
同意。やれやれだよ。
>>54あたり本気なのかネタなのかすら判別がつかん。

何でこんな基礎的な話で議論になるのか…。


57 :NAME IS NULL:05/01/06 06:11:50 ID:???
主キー指定して取得するからピンポンが発生するんだろ。
なぜ、主キー指定して取得してるのに、ピンポンを発生させているのか考えれば、
わかる話だろう。
まともなSQL書けばすむ話だ。
ストアド以前の話だな。
よってインデックスが正しい。

58 :NAME IS NULL:05/01/06 08:33:10 ID:???
>>57
( ゚Д゚)ポカーン

考えれば分かる話だろう。
じゃなくて、そこんとこ詳細に説明してみ。
どんな珍説なのか是非聞いてみたい。

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:???
>>57 の考え、休むに似たり」

>よってインデックスが正しい。

>>55
>二重にインデックスを張る行為には _全く意味がない_。

62 :NAME IS NULL:05/01/06 12:00:46 ID:???
>>61
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 = ?
で索引を使ったり使わなかったりしたのもあったけど最近のは大丈夫ですよね?

64 :NAME IS NULL:05/01/06 15:01:59 ID:???
>>57
想像するに…
・一行ずつ取得ではなく、複数行持ってきてUPDATEはループで回せ。
・UPDATE一発でやれ
のどちらかを言いたいのだと思うけど、それじゃ出来ない処理なんて
いくらでもある。そう言うときの為にストアドがある。

そもそも
「ストアドが存在するDBMSにもかかわらずクライアントでバッチ更新」
なんて仕様が出てくる時点で間違い。

>>63
> 最近のは大丈夫ですよね?
そうでもないよ。

65 :NAME IS NULL:05/01/06 15:14:53 ID:???
>>64
物事には順序がある。
一行ずつ取得してる新人に、いきなりストアドでやれとは言わない。
ストアドなどという前にやることがあるだろう。

66 :NAME IS NULL:05/01/06 17:01:57 ID:???
>>65
VBでバッチ処理が書けてストアドだと書けないなんて事があるか
どう考えてもストアドの方が簡単だろう。

単なる怠慢。

67 :NAME IS NULL:05/01/07 18:59:59 ID:???
ストアドでバッチ処理を書き直したまではいいのだけれど、
数件おきにコミットさせるとカーソルがクローズしてエラーになってしまう。
1件分の処理の間に子レコードの処理も入るのでトランザクションは使いた
いのだが全部処理するには総数が大きい。さてどうするべ、週末なのに・・・

68 :NAME IS NULL:05/01/07 19:30:04 ID:???
やかん

69 :NAME IS NULL:05/01/07 19:52:36 ID:???
>>67
Oracle で、FOR UPDATE 付きの問い合わせをしてるなら
それは仕様。ROWID 使え。
Oracle じゃないなら知らん。
つか、スレ違い。

70 :NAME IS NULL:05/01/07 19:54:15 ID:???
>>67
コミット後にカーソルをオープンしたままにする方法はないの?
大抵のDBMSならできるはずだけど。

71 :NAME IS NULL:05/01/08 00:52:36 ID:/A2kgL9D
そこでインデックスですよ。

72 :NAME IS NULL:05/01/12 23:38:32 ID:???
>>57でキーボードに茶を吹いたよ。 どうしてくれる。
>>64はきっと釈迦のような慈悲の心を持っているんだろうな。

73 :NAME IS NULL:05/01/13 00:41:48 ID:???
確かに>>57って笑えるw


74 :NAME IS NULL:05/01/13 23:21:13 ID:Yo88RG9E
>>70
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でも同じ
じゃねーか。

78 :NAME IS NULL:05/01/16 02:14:22 ID:???
>>77

カーソルループでの更新が途中でこけると、どこまでやったかがわかんないから最初からやり直すことになると思うけど。
このとき、途中までCOMMITしてたらそこまでの更新をもう1回やることになる。
それでも整合性がとれるようなケースってあんましなさそうな気がするけど...



79 :NAME IS NULL:05/01/16 10:18:16 ID:???
>>78
その通り。

>>77のケースはやろうとすれば出来るだろうけど、
管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。



80 :NAME IS NULL:05/01/16 12:25:52 ID:???
そのあたり、セーブポイントでどうにかできないのでしょうか。

81 :NAME IS NULL:05/01/16 19:27:34 ID:???
そもそもセーブポイントって、どういうものか理解しているのか?


82 :77:05/01/16 20:28:02 ID:???
>>78,79
カーソルループの中で整合性が取れるケースって、珍しくはないよ。
いくつか思いつくけどね。
例えば、受注テーブルを基に、物流システムへ渡す出荷指示データ
を作成するバッチ処理とか。
受注テーブルの出荷指示フラグと出荷日を基にカーソルループでまわす
場合。で、ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
テーブル更新、出荷指示テーブル作成とかやってる場合、処理する受注伝票
単位で整合性が取れてれば問題ないというケース。

>管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。

正直、意味が良くわからん。多分、管理が非常にむずかしくなるってのは、
どこまでコミットしたかを把握したいという意味なんだろうけど。

すでにコミットしたデータは、整合性が取れてるわけだから、基本的には気に
する必要はない。プログラムの不具合で、コミットしたデータの信頼性が損なわれている
場合でも、テーブルに更新時のタイムスタンプと最終更新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の回答も俺とおんなじ理解だろ。
話の本質が分かってないのは、お前のほうじゃねーかって気がするがな。

85 :NAME IS NULL:05/01/17 11:13:38 ID:???
>>84
67に対しては69でFA出てる。
そこから先の話はトランザクション内でのコミットの是非についてだろ。

86 :NAME IS NULL:05/01/17 11:15:32 ID:???
訂正
67に対しては70でFA出てる



87 :77:05/01/17 12:47:35 ID:1w1sWpKp
>>85
>そこから先の話はトランザクション内でのコミットの是非についてだろ。
そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
整合性を確保できる最小単位であることだ。(原子性、一貫性)

俺が77で言っているのは、カーソルループ1回単位が1トランザクション
の場合と、カーソルループ全体が1トランザクションの場合の話。

>>67に対しては70でFA出てる
やっぱり話の本質が分かってないのは、お前のほうだと思うがな。俺は、
70に対する返答(74)に対して、77で返答してんだから。
どこから、トランザクション内でのコミットの是非についてになったん
だ。

88 :NAME IS NULL:05/01/17 13:26:16 ID:???
>>87
言ってる意味がさっぱりわからん
とりあえず落ち着け

89 :!= 77:05/01/17 13:58:39 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:???
>>90
>>67 以降、違う話に花が咲いています。

92 :NAME IS NULL:05/01/18 01:10:45 ID:???
>>90

>>91の言うように、話題が変わってます。
カーソルループで大量更新をする場合の話。

>>87,88
想定している状況がそれぞれ違ってるみたいだから
ちょっとこじれかけてるけど、めずらしくまともな議論
に育ちそうだからマターリいこーぜー。



93 :77:05/01/31 01:00:05 ID:???
すごい遅レスだが。

>そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
>整合性を確保できる最小単位であることだ。(原子性、一貫性)

これは、トランザクションは整合性を確保する最小単位だから、
トランザクション内部でのコミットは有り得ないということが
言いたかった。


27 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)