過去の桐井戸端ＢＢＳ　（桐ver.９）
19596 外部ＤＢ接続の性能についてどのようにすれば改善されるのでしょうか たぬきっち 2003/03/24-14:51
桐の外部ＤＢを使用されている方教えてください。

桐で基幹システムを構築を考えており、性能検証を行っています。
MSDEを使用した場合、結合文で亀が走り遅くなります。
桐は共有した場合の索引を使用しないとか、共有すると極端に遅くなる
ため、ＭＳＤＥを使ってみたのですが、もっと遅くなりました。
外部ＤＢを使用する目的として性能改善があるとおもいますが
どのように使用されているのでしょうか？


＜検証内容＞
１．サーバ(Win2000Server)の表の検索が何秒か（参照モード、索引あり)
２．外部ＤＢ(MSDE:同上サーバ)の表の検索が何秒か（参照モード、索引あり)


＜検証条件＞
表:約11000件 レコード長=700バイト
CLスペック:P4
他のMSDE使用者はいない

＜検証結果＞


桐表 1.892秒
MSDE　95.668秒

　　
<一括処理>
印字開始 #一括パス名 + "検証結果.TXT",追加,終了状態=&ＦＯＫ
&ＭＳＧ = "桐 XXXX.TBL "
&開始日時 = #日時値
印字 &一括処理名,&ＭＳＧ,"START",&開始日時
表 #一括パス名 + "XXXX.TBL",モード=参照,索引名="日付",終了状態=&ＦＯＫ
検索 [日付]{D"1919/11/19"}
終了 表 *
&終了日時 = #日時値
印字 &一括処理名,&ＭＳＧ,"END ",&終了日時
印字 &一括処理名,&ＭＳＧ,"実行時間 ",#時間数値(#日時時刻(&終了日時),3) - #時間数値(#日時時刻(&開始日時),3),"秒"

&ＭＳＧ = "MSDE 日報2002.xvw "
&開始日時 = #日時値
印字 &一括処理名,&ＭＳＧ,"START",&開始日時
結合 #一括パス名 + "XXXX.xvw"
検索 [日報.日付]{D"1919/11/19"}
終了 表 *
&終了日時 = #日時値
印字 &一括処理名,&ＭＳＧ,"END ",&終了日時
印字 &一括処理名,&ＭＳＧ,"実行時間 ",#時間数値(#日時時刻(&終了日時),3) - #時間数値(#日時時刻(&開始日時),3),"秒"
印字 " "
印字終了 改ページ=しない


19598 Re:外部ＤＢ接続の性能について うにん 2003/03/24-15:21
記事番号19597へのコメント
>MSDEを使用した場合、結合文で亀が走り遅くなります。
>桐は共有した場合の索引を使用しないとか、共有すると極端に遅くなる
>ため、ＭＳＤＥを使ってみたのですが、もっと遅くなりました。
>外部ＤＢを使用する目的として性能改善があるとおもいますが
>どのように使用されているのでしょうか？

結合表の定義が不明ですが、絞込条件を指定しないと桐の表より
速くなる可能性はゼロだと思います。

>>結合 #一括パス名 + "XXXX.xvw"
>>検索 [日報.日付]{D"1919/11/19"}

結合してから検索するのでなく、パラメータ変数を使って検索条件を
絞り込み条件に含めて、結合結果の行数が極力少なくなるようにします。

19599 Re:外部ＤＢ接続の性能について hidetake 2003/03/24-15:56
記事番号19596へのコメント
>桐で基幹システムを構築を考えており

スピードの問題とは少しずれますが，桐の外部DB を使う場合
参照だけだったら特に問題は無いと思いますが，
更新まで必要な場合は相当工夫が必要だと思います。

基幹システムだとか共有時の事を考えて，外部DB を検討されておられるようですが，
桐の外部DB で実表を更新する場合，
桐に取り込んだデータを where句無しに(要は更新前の値を条件として付加せずに) update をかけています。
だから，別のユーザがいて先に更新がかけられていても，
更新の発生の有無を問わず，自分のデータで上書きしてしてしまいます。

と言う事で，複数のユーザでデータの更新が発生する場合は
よほど工夫してシステムを作る必要がある(桐内部だけの処理では済ませられない)と思います。

19601 Re:外部ＤＢ接続の性能について hidetake 2003/03/24-17:01
記事番号19599へのコメント
桐の外部DB で気をつけた方が良い事など
http://www.icity.or.jp/usr/ogou/cgi-bin/Kiri.cgi
の過去のコメントを見れば，少しは参考に
なる事もあるかも知れません？


蛇足
桐は「長さ 0 の文字列」を扱えないので
Null値は禁止してあっても，「長さ 0 の文字列」は許容している場合，
この「長さ0 の文字列」を自分では入れ直す事は出来ません。

要は "" と #u (#未定義)を区別してくれないわけですが，こんな項目に対して ""
あるいは #u で置換をかけた場合，桐Ver8ではエラーが出ていたのに，
桐ver9 は１度目は何もエラーは発生せずに通ってしまう！
通ると言ってもデータに変化は無いのだが，
エラーも発生せずにカーソルが終端行に移動する。
同じ事を２度繰り返すと今度はエラーが発生するのだが，
どうも挙動が変だ？　:-)

19602 Re:外部ＤＢ接続の性能について たぬきっち 2003/03/24-17:04
記事番号19598へのコメント
うにんさん、こんにちは
>結合してから検索するのでなく、パラメータ変数を使って検索条件を
>絞り込み条件に含めて、結合結果の行数が極力少なくなるようにします。
>
結合に絞り込み条件を使用していませんでしたの
絞り込み条件に変数を設定し実行した結果
7.05秒になりました。
（それでもちょっと遅いですね、実際、ユーザ間で共有したときのパフォーマンスがよいのかもしれませんね)
結合文を単なるテープルのＯＰＥＮかと勘違いしておりました。
うにんさん、どうもありがとうございました。
19605 Re:外部ＤＢ接続の性能について たぬきっち 2003/03/24-17:26
記事番号19599へのコメント
hidetakeさん、こんにちは
>だから，別のユーザがいて先に更新がかけられていても，更新
>の発生の有無を問わず，自分のデータで上書きしてしてしまい
>ます。

まだ、そこまで調べてはないですけど、レコード排他がかからないということですね、
いわれてみれば桐はモードの設定とトラン開始くらいしか制御はありませんね、
ＭＳＤＥ側の設定でレコード排他が可能なのか
ＭＳＤＥも今回使用するは初めてなのでもうちょっとしらべてみます。

>
>と言う事で，複数のユーザでデータの更新が発生する場合は
>よほど工夫してシステムを作る必要がある(桐内部だけの処理
>では済ませられない)と思います。
>

そうですね、テーブル構造などを工夫してＵＰＤＡＴＥ、ＤＥＬＥＴＥ
の発生しないシステムが理想ですね。
アドバイス、ありがとうございます。

戻る