過去の桐井戸端BBS (桐ver.9) |
29685 | 未定義を含むor条件での検索がうまくいかない | しぼうかん | 2005/04/21-13:52 |
数値型の[得意先ID]と文字列型の[社名]の2つの項目があり、 [社名]が"山田電気"で[区分連番]が未定義または"8"のレコードを 検索したいと思っています。 ※"山田電気"と"8"は質問用に仮に設定しただけの値で実際の検索の値には変数を使います。 そこで以下のコマンド文を左クリックイベントに書いて見ましたが 検索 [区分連番]{[社名]="山田電気",[区分連番]=#cond([区分連番]=8,8,[区分連番]="","")} うまく行きません。どうすればいいのでしょうか? | |||
29686 | Re:未定義を含むor条件での検索 | うにん | 2005/04/21-16:04 |
記事番号29685へのコメント >数値型の[得意先ID]と文字列型の[社名]の2つの項目があり、 >[社名]が"山田電気"で[区分連番]が未定義または"8"のレコードを >検索したいと思っています。 [得意先ID]は無関係なようですが。[区分連番]が数値で、 未定義項目値処理が「0」になってるのでは? | |||
29691 | Re:未定義を含むor条件での検索 | しぼうかん | 2005/04/21-19:28 |
記事番号29686へのコメント うにんさん返信ありがとうございます。 >[得意先ID]は無関係なようですが。[区分連番]が数値で、 >未定義項目値処理が「0」になってるのでは? [得意先ID]は[区分連番]の書き間違いです。すいません。m(_ _)m 未定義項目値処理は「0」になっています。 しかし別の項目で計算をする為にこれは「0」にして置きたいのです。 ※項目ごとに未定義項目値処理の設定は出来ないですよね? | |||
29692 | Re:未定義を含むor条件での検索 | アックン | 2005/04/21-19:49 |
記事番号29685へのコメント しぼうかんさん、こんにちは。 実際にやってみたところ、その検索コマンドで間違いないです。 「実際の検索の値には変数を使います」ということですが、こんなふうにしているんですか? &STR="山田電気" , &秒=8 , &分="" 検索 ∨,[区分連番]{[社名]=&STR,[区分連番]=#cond([区分連番]=&秒,&秒,[区分連番]=&分,&分)} こうしてもちゃんと検索します。 「うまくいきません。」とのことですが、 エラーコマンドが出ますか? まったく検索しないですか? 思いがけない値を検索しますか? >うにんさん 表の未定義項目値処理が 0 でも 未定義 でも、結果は同じでした。 アックン(=^・^=) | |||
29695 | Re:未定義を含むor条件での検索 | うにん | 2005/04/21-21:12 |
記事番号29692へのコメント >「うまくいきません。」とのことですが、 >エラーコマンドが出ますか? >まったく検索しないですか? >思いがけない値を検索しますか? そこが問題ですよね。ここに限らず、質問するとき書かない人が多いですね。 >表の未定義項目値処理が 0 でも 未定義 でも、結果は同じでした。 だはは。違うことやってました^^; #cond([区分連番]=8,8,[区分連番]="","") でなく #cond([区分連番]=8 .or [区分連番]="",[]) ということをやると、項目値を参照するので関係してくるの。 ところで、これって後の条件は無意味ですね。 #cond([区分連番]=8,8,[区分連番]="","") 一致する条件がなければ結局未定義が返るので、これだけでも同じ。 #cond([区分連番]=8,8) | |||
29707 | Re:未定義を含むor条件での検索 | アックン | 2005/04/22-11:12 |
記事番号29695へのコメント >ということをやると、項目値を参照するので関係してくるの。 つうことでやってみたけど、未定義項目値処理は関係してないみたい。(?) >一致する条件がなければ結局未定義が返るので、これだけでも同じ。 お、そっだね。 これ(↓)でいいと思います。 #cond([区分連番]=8,[]) | |||
29709 | 解決しました。 | しぼうかん | 2005/04/22-11:44 |
記事番号29685へのコメント うにんさん、アックンさん、返答ありがとうございました。 そしてごめんなさい。m(_ _)m 検索する為の区分連番の値として未定義を代入したつもりが0が代入されていました。 というわけで解決しました。 | |||
29710 | Re:未定義を含むor条件での検索 | うにん | 2005/04/22-12:45 |
記事番号29707へのコメント >>ということをやると、項目値を参照するので関係してくるの。 >つうことでやってみたけど、未定義項目値処理は関係してないみたい。(?) あれ〜? 「検索と絞り込み、グループ選択時は、未定義値をつねに未定義として扱います。」 と書いてありますが、あくまで検索等の対象の項目として参照されてる方だけで、 比較値の側では関係してくるはずだったのですが。 絞り込み:値で、[]と指定すると未定義項目値処理に関係なく常に全行選択されますが、 []+[]と指定すると処理=ゼロだと未定義の行は選択されません。 両辺とも計算式が使えるようになったので、どっち側かでなく項目名だけが指定されてるか で処理が変わるようになってるのかな?(前からそうだったかも) >#cond([区分連番]=8,[]) ということで、こういう書き方で自動的に「未定義を含むor」になっているので 逆に未定義を含めたくない場合は要注意なわけです。 んで、私がやってたのは本当は #cond([区分連番]=8,8,[区分連番]="","",1,[区分連番]+1) のようなことでした。 これだと処理=ゼロだと未定義が選択されなくなります。 | |||
29712 | あとがき | しぼうかん | 2005/04/22-17:41 |
記事番号29709へのコメント 今回の問題は単なる検索の問題ではありませんでした。 桐の仕様なのか、それともデータベース一般の仕様なのか、 よくわかりませんが以下の現象が原因でした。 最初は"検索A"のコマンド文を書いてうまく行かず、 次に"検索B"のコマンド文を書いてうまくいかず、 検索がうまく行かないのか?と早合点して投稿しましたが 結局"検索Cのコマンド文を書くとうまく行きました。 しかし[区分連番]の値が検索の中で使うときはの時は 未定義扱いでうまく行き、条件やifコマンドの時には0扱いで うまく行く不思議な仕様にはなかなか気がつきませんでした。 検索A 検索 [区分連番]{[社名]="山田電気",[区分連番]=#cond([区分連番]=8,8,[区分連番]="","")} 条件(.not#eof .and [区分連番]<>"")確認 "不正解です" 条件(.not#eof .and [区分連番]="")確認 "正解です" 検索B 検索 [区分連番]{[社名]="山田電気",[区分連番]=#cond([区分連番]=8,8,[区分連番]=0,0)} 条件(.not#eof .and [区分連番]<>0)確認 "不正解です" 条件(.not#eof .and [区分連番]=0)確認 "正解です" 検索C 検索 [区分連番]{[社名]="山田電気",[区分連番]=#cond([区分連番]=8,8,[区分連番]="","")} 条件(.not#eof .and [区分連番]<>0)確認 "不正解です" 条件(.not#eof .and [区分連番]=0)確認 "正解です" 検証しやすいように一応ファイルをUPしました。 | |||
29714 | Re:あとがき | アックン | 2005/04/22-18:54 |
記事番号29712へのコメント しぼうかんさん こうすればうまくいくと思いますよ。 検索 ∨,[区分連番]{[社名]="山田電気",#cond([区分連番]="",[],[区分連番]=8,[])} if( .not#eof .and(.not[区分連番] .or[区分連番]=8 ) ) 確認 "正解です" else 確認 "不正解です" end | |||
29722 | Re:あとがき | 悲しげ | 2005/04/22-23:51 |
記事番号29712へのコメント 解決済みのようですが(^^;) >検索 [区分連番]{[社名]="山田電気" ,[区分連番]=#cond([区分連番]=8,8,[区分連番]="","")} この記述の意図がよく判りません。仮に[社名]の部分を無視すれば、 検索 [区分連番]{[区分連番]=#cond([区分連番]=8,8,[区分連番]="","")} となりそうですから、とすれば、これって要するに[区分連番]の値が8またはヌルの値を検索しているのではありませんか? とすれば、私なら(DOS以来の古い書き方ですが) 検索 ∨,[区分連番]=#cond([社名]="山田電気" .and ([区分連番]<1 .or [区分連番]=8) ,[],[],#u,1,1) if(#EOF .or [区分連番]>0) 確認 "不正解です" else 確認 "正解です" end ※出典はいわゆる『酒井本』です。 未定義は0より小さいことを利用していますが、[区分連番]の値に マイナスはありませんよね?(^^;) | |||
29728 | アックンさんと悲しげさんへ | しぼうかん | 2005/04/23-13:31 |
記事番号29712へのコメント この掲示板で質問をすると質問事項以外の部分でも新知識を教えて頂ける場合が多いので助かっています。 悲しげさん、いつも返答ありがとうございます。 >となりそうですから、とすれば、これって要するに[区分連番]の値が8また >はヌルの値を検索しているのではありませんか? はいそうです。 そこで早速使ってみましたが[社名]=山田電気で[区分連番]=8で検索すると終端行へいってしまいました。 なおヌルの値が<0で検索出来るとは知りませんでした。 この知識はいろいろな場面で応用が利きそうです。 早速今回もこの部分を使ってアックン+悲しげさんのコマンド文を編集して 別のもっとすっきりした書き方でも検索が出来るようになりました。 時々"酒井本"という引用が出てきますがかなり優秀な本だったんでしょうね。 一応現象が簡単に解るようにファイルをUPして置きました。 アックンさん、いつも返答有り難うございます。 早速使って見ましたが検索はうまく行きましたが、if文のところで [社名]=山田電気で[区分連番]が6の時ではうまく分岐が出来ませんでした。 説明がヘタなのでファイルを再度UPしました。 とりあえずアックンさんの検索部分と悲しげさんのif文部分とを編集加工するとうまくいきました。 このコマンド文の方がすっきりしているのでこっちのコマンド文を使う事にしようと思います。 | |||
29729 | Re:未定義を含むor条件での検索 | しぼうかん | 2005/04/23-13:38 |
記事番号29695へのコメント >>「うまくいきません。」とのことですが、 >>エラーコマンドが出ますか? >>まったく検索しないですか? >>思いがけない値を検索しますか? >そこが問題ですよね。ここに限らず、質問するとき書かない人が多いですね。 つい自分が解っていることは相手も解っているつもりになって書き漏れをする事が多々あったりします。いけませんね。 以後気をつけたいと思います。 ※気をつけますと言い切れないのは自分の記憶に自信がないので(^^;) | |||
29730 | 補足説明です。 | しぼうかん | 2005/04/23-13:46 |
記事番号29729へのコメント といいつつ早速説明漏れでした。 書き込みで説明するより実際のファイルを見て貰った方が説明がわかりやすいと思います。 ファイルをUPしてありますのでもしよかったら見て下さい。 | |||
29733 | Re:補足説明です。 | 悲しげ | 2005/04/23-18:24 |
記事番号29730へのコメント メッセージで曰く >この検索では&区分連番値が[区分連番]に無かった場合 >例えば社名が山田電気で区分連番が8だった場合、 >終端行までいってしまいました。 と云うことが「問題点」とされていますが、これって「問題点」と云うより、 至極当然の、むしろ「期待どおりの」結果のような気がするのですが。(?_?) もし、検索に失敗した時に、処理対象行が終端行に行かないようにしたいと 云うことであるなら、「検索」コマンドに「終了状態」パラメータを付ける 方法もあります。そして、その終了状態変数の返り値でメッセージ文言を変更するとか。 この辺り、しぼうかんさんが何をやりたいのか、やはりよく判りませんが、 もしかして、[社名]と[区分連番]をそれぞれ独立して検索させてメッセージ文言も変えたいのであれば、例えば 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 絞り込み [社名]{&社名} *★ if(&選択件数>0) 検索 [区分連番]{&区分連番},終了状態=&終了 if(&終了=1) 確認 "社名="+&社名+"で連番値="+#str(&区分連番)+"のデータ有り" else 確認 "社名="+&社名+"はあれど連番値="+#str(&区分連番)+"のデータ無し" end else 確認 "社名="+&社名+"のデータがそもそも無し" end 解除 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 あるいは、もしかして区分連番が0とヌルを同一として扱いたいと云うのが、 問題の中心であるのなら(?_?)、例えば上記★印部分に cond(&区分連番=0) &区分連番="" としておくとか(ちとダサイかな?)。(^^;) あ、メッセージ文言用の別変数(文字列)を用意して &文言=#cond(&区分連番>0,#str(&区分連番),1,"0 or ヌル") とでもしておいて 確認 "社名="+・・・・+"連番値="+&文言+"のデータ・・・" とか。ぅぅぅ、何だかドロドロに・・・・(^^;) やはり今回もしぼうさんのやりたいことがよく判らなかったです。 | |||
29737 | 次回はもっとうまく説明・・・ | しぼうかん | 2005/04/24-13:09 |
記事番号29733へのコメント また×を貰ってしまいました。最初の投稿文がまずかったんでしょうか。 意図していたのは 1.まず[社名]と[区分連番]をそれぞれ指定値(変数)で検索する。 2.1.で一致した値がなければ[社名]が指定値(変数)と一致して[区分連番]が未定義の値を検索する。 3.1.又は2.で検索して一致したレコードにいろんな事(行訂正他)をする。 という処理の1.と2.を一度の検索でして3.をする為の方法が知りたくて投稿しました。 3.の処理を行訂正で無くて確認コマンドで書いたのは単に複雑に書きたくなかったからでした。 ※なおこれは又書き漏れなんですがこの表は[社名]が有り[区分連番]が未定義のレコードが[社名]が有り[区分連番]の上には無いようになっています。 >もし、検索に失敗した時に、処理対象行が終端行に行かないようにしたいと [社名]が"山田電気"で一致して[区分連番]が8のレコードが無い場合は 検索に失敗した訳では無くて次の条件の[社名]が"山田電気"で[区分連番]が未定義の レコードを検索を実行して欲しかったのです。 なお今回の質問には関係がないので書いていませんが今回の処理の全体は 1.〜3をするための変数は他にも有り(&金額など)その値を他の表で代入し、 この表の別項目[金額]などに加算するという事を繰り返しコマンドを使って実行する、 併合もどきのような処理をしています。 なのでせっかく書いていただいたのですが絞り込みを使ったコマンド文では 今回の処理にはちょっと使えませんでした。 追伸. 今回もうまく説明できず泥沼に引き入れてしまいました。 そこで説明方法についてよ〜く熟考してみた結果、次回からはやりたい事の意味を 説明しようとするだけでなく実際に動いて欲しい挙動自体をそのままを書く という説明を取り入れて説明してみる事にします。 | |||
29738 | Re:次回はもっとうまく説明・・・ | 悲しげ | 2005/04/24-15:48 |
記事番号29737へのコメント まだ半分くらいしか意図を読めておりませんが(^^;) >1.まず[社名]と[区分連番]をそれぞれ指定値(変数)で検索する。 >2.1.で一致した値がなければ[社名]が指定値(変数)と一致して > [区分連番]が未定義の値を検索する。 やはり1と2は二段構えで処理する方が何かと簡単だし、激しく無難なのではないでせうか? 例えば 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 検索 [社名]=#cond([社名]=&社名 .and [区分連番]=&区分連番\ ,[],[],#u,1,"1"),終了状態=&終了 if(&終了<>1) /*上記検索で該当なしの場合*/ 検索 [社名]=#cond([社名]=&社名 .and [区分連番]=""\ ,[],[],#u,1,"1"),終了状態=&終了 if(&終了<>1) 確認 "社名="+&社名+"で区分連番がヌルのデータ無し" ・・・・・ else ・・・・・色々なこと(1) end else /*一発の検索で存在した場合*/ ・・・・・色々なこと(2) end 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 ちなみに初めの「検索」を、多項目1回の「検索」ではなく[社名]項目のみの 「絞り込み」でやった方が、考え方としても簡単だし、処理速度も速くなるのではないかと、私は思うのですが。(?_?) ま、こだわるつもりもありませんが、 >なのでせっかく書いていただいたのですが絞り込みを使ったコマンド文 >では今回の処理にはちょっと使えませんでした。 どうして、「なので」で始まるのかがちょっとだけ不思議に思いました。 随所でその都度、絞り込み解除すればいいだけではないのか、と。 それと、本旨に影響しないことなのでしょうけど >この表は[社名]が有り[区分連番]が未定義のレコードが >[社名]が有り[区分連番]の上には無いようになっています。 この部分は日本語として成立していなくて、意味が全然とれません。(^^;) タイプミスですかね? | |||
29739 | Re:次回はもっとうまく説明・・・ | 悲しげ | 2005/04/24-16:15 |
記事番号29738へのコメント >ちなみに初めの「検索」を、多項目1回の「検索」ではなく[社名]項目 >のみの「絞り込み」でやった方が、考え方としても簡単だし、処理速度 >も速くなるのではないかと、私は思うのですが。(?_?) なぜ速くなるのかを、一般論的に補足説明しておきます。 仮に全部で三万行のデータがあるとして、その内"やまだでんき"が三千行あったとします。 初回の検索では、この三万行から探します(ちなみに、複数項目検索だと索引も使えない)。 で、2度目の検索でも、また改めて三万行から探すことになります。 これが初回を1項目のみの絞り込みだと、ま、三万行から探すことにはなるのですが (単項目で扱うので索引も利用できそう)、2回目の別項目で の検索では、絞り込まれた三千行からの検索となるので(索引は使えないとしても)、速度的には段違い平行棒。 ついでに云えば、後者の方がアルゴリズムも簡単になりそうな予感もあるのですが、 それについては細部が読めないので違うかもしれません。 | |||
29743 | Re:次回はもっとうまく説明・・・ | うにん | 2005/04/25-09:33 |
記事番号29738へのコメント >ちなみに初めの「検索」を、多項目1回の「検索」ではなく[社名]項目 >のみの「絞り込み」でやった方が、考え方としても簡単だし、処理速度 >も速くなるのではないかと、私は思うのですが。(?_?) 私もそう思います。 >随所でその都度、絞り込み解除すればいいだけではないのか、と。 これが、桐の強みなんですよね。 ファイルメーカーあたりだと、「解除」とか「絞り込み段数」の概念がないのでとても面倒。 >>この表は[社名]が有り[区分連番]が未定義のレコードが >>[社名]が有り[区分連番]の上には無いようになっています。 > >この部分は日本語として成立していなくて、意味が全然とれません。(^^;) 上から検索した時に、OR条件で先に見つかるのが必ず[区分連番]ありの レコードだということでしょう。 「検索」というのはどっちかというと表計算なれした人向きの機能で、 データベース的には(一括処理では?)ほとんど使う必要のないものだと思います。 (検索したレコードの上とか下のデータが必要な場合に使うんでしょうけど、 「上とか下」に意味があること自体がデータベース的でない。) | |||
29746 | わかりやすい(つもり)方の説明です。 | しぼうかん | 2005/04/25-18:26 |
記事番号29737へのコメント 多分解りにくい方の説明では?マークが大量発生する可能性が高いので、 やりたかった事とほぼ同じプログラムを書いたファイルをUPしました。 今まで説明していた[社名]は[担当者]に、[区分連番]は[得意先ID]に読み変えて見てください。 もう一つのコメントは適当に流し読みで結構です。 | |||
29747 | 解りにくい方の説明です。 | しぼうかん | 2005/04/25-18:38 |
記事番号29737へのコメント 悲しげさん、うにんさん難解な文章を読んで頂きありがとうございます。 実はこちらを先に書いたのですが読み返してみると正しく意志を伝えられる自信が全く無かったので 実際の物に近いファイルをUPしました。しかし書いた物を捨ててしまうのもどうかと思ったので 一応投稿します。適当に流し読みでけっこうです。(^^;) >初回の検索では、この三万行から探します(ちなみに、複数項目検索だと >索引も使えない)。で、2度目の検索でも、また改めて三万行から探すこ >とになります。 NO.29737の1.2.3.の説明はつまり 「1.の検索で先頭行から最終行まで検索して無ければ2.の検索でまた先頭行から最終行まで検索する」 という2回検索を行うという意味では無くて 「まず先頭行で1.の条件での値があるかどうか"調べる"。無ければ同じレコードに対して2.の条件で調べる。 そして先頭行が条件に合わなければ2行目にジャンプしてまた同じように1.と2.の条件に合う物を"調べる"・・ 以下条件が合うレコードが見つかるか、見つからない場合は最終行まで1行ジャンプを繰り返す」 という"1回"の検索についての説明でした。 >どうして、「なので」で始まるのかがちょっとだけ不思議に思いました。 「2項目([社名]と[区分連番])or条件での1回の検索」より「1項目([社名]で絞り込み+1項目([区分連番])で 検索」の方が処理が早いはずが無いので」 という文章を自分の脳内で省略して「なので」と書きました。(それともこの前提が間違っているのでしょうか?) 例えば補完BBSにUPした表で[社名]=山田電気で[区分連番]=8又は未定義のレコードを探す場合。 先頭から5行目と6行目に[社名]="山田電気"で[区分連番]が未定義である「条件にあうレコード」が有ります。 「2項目or条件での1回の検索」で検索すれば桐の内部の検索プログラム?が調べるレコードは5行目で条件に合ったレコードが 見つかる為5行目以降は検索しない、つまり5行だけですが、「1項目で絞り込み+1項目検索だと」 まず1項目での絞り込みで8行、次に絞り込まれた4行の内の3行目に[社名]="山田電気"で[区分連番]=未定義の レコードがあるので3行、つまり8行+3行の合計11行を調べる。 言いたいことは「2項目or条件での1回の検索」では5行調べる<「1項目絞り込み+1項目検索」では11行調べる。 となって「2項目or条件での1回の検索」の方が 調べる行数が少ないので処理が早いのではないかな?という事です。 さらに少し推理してみました。UPしたファイルには[社名]="山田電気"で[区分連番]=""のレコードが2行ありますが、 この2つの行両方に"色々な処理をする"と考えられているのでしょうか? もしそういう風に理解されているならば、そうではなくて、検索して「最初に見つかった1行に対してだけ」色々な処理をします。 >この部分は日本語として成立していなくて、意味が全然とれません。(^^;) >タイプミスですかね? うにんさんがフォローして下さった通りの意味で 上から検索した時に、OR条件で先に見つかるのが必ず[区分連番]ありの レコードだということです。 | |||
29748 | Re:解りにくい方の説明です。 | うにん | 2005/04/25-20:37 |
記事番号29747へのコメント >「2項目([社名]と[区分連番])or条件での1回の検索」より「1項目([社名]で絞り込み+1項目([区分連番])で >検索」の方が処理が早いはずが無いので」 > >という文章を自分の脳内で省略して「なので」と書きました。(それともこの前提が間違っているのでしょうか?) 微妙ですね。悲しげさんの推測では後者の方が索引が使えて早いのではないか、ということですよね。 >「2項目or条件での1回の検索」で検索すれば桐の内部の検索プログラム?が調べるレコードは5行目で条件に合っ >たレコードが見つかる為5行目以降は検索しない、つまり5行だけですが、「1項目で絞り込み+1項目検索だ >と」まず1項目での絞り込みで8行、次に絞り込まれた4行の内の3行目に[社名]="山田電気"で[区分連番]=未定義 >の >レコードがあるので3行、つまり8行+3行の合計11行を調べる。 >言いたいことは「2項目or条件での1回の検索」では5行調べる<「1項目絞り込み+1項目検索」では11行調べ >る。となって「2項目or条件での1回の検索」の方が >調べる行数が少ないので処理が早いのではないかな?という事です。 こういう行数がとても少ないケースではたいてい索引を使わない方が早くなると聞いたような。 (索引を使うと索引から検索した後実データを探しに行くという手間もあるので。たしか昔のpostgresqlでは 1000行以下では絶対使わないとかいう話だったような) 索引を使った絞込みでは、該当行だけ調べることが期待できます。悲しげさんの仮定データ >仮に全部で三万行のデータがあるとして、その内"やまだでんき"が三千行 であれば、「1回の検索」では平均して真ん中辺に見つかるとして15000行、「絞り検索」では3000+1500=4500行 となるでしょう。(上記の「検索した後実データを探しに」を考えても3000+3000+1500=7500位) 整列かけたデータをシーケンシャルに処理する必要がある場合はしょうがないですが、 それ以外の場合はどかっと絞り込んで処理する方が気分的にはすっきりします。 ま、実際に作った処理が遅くて困ってるというんでもない限り、自分のわかりやすい方でいいと思いますが^^ | |||
29749 | Re:適当に流しコメント | 悲しげ | 2005/04/25-22:20 |
記事番号29747へのコメント おそらく本旨には無関係なことだろうと思うので、「適当に流し」程度に(^^;) 簡単にコメントしておきます。 「なので」の速度論は、私は「その上さらに速度から云っても」と書いたまでで、 しぼうかんさんが書いた「なので」は、速度の問題ではなくて、 多分「繰り返し」「併合もどき」だからだったような気がしていますから、 私の「ちょっと不思議」は未解決です。が、未解決のままでも私としては構いません。 それに数十〜数百行くらいのデータだったのなら、いずれにせよ検索速度には殆ど影響ないでしょうね。 それと「上」ですが、これって「前」のことだったんですね。(^^;) レコードの並びは普通は「前行」とか「次行」とか云う訳で、「上行」とか 「下行」とは云いませんからね。オブジェクトの重なりとかで上(手前)、 下(奥)ってのがありますから、その3次元感覚で「上」って何だ?と。(^^;)(^^;) いずれにせよ、複数回の検索(絞り込み含む)相当を一発の検索で済ませようと云うのは、 かなり無理があるとの私の思いは変わりません。 たとえレコード並びの「前後」が決まっていようとも。(これが私の暫定結論かな) >さらに少し推理してみました。・・・・・ >この2つの行両方に"色々な処理をする"と考えられているのでしょうか? いえ、そのような推理は全くしてません。1行についてだと「推理」しておりましたよ。 ・・・・これ以上は無駄なやりとりになりそうなので、コメント無用です。 | |||
29755 | 索引のイメージが変わりました。 | しぼうかん | 2005/04/26-19:44 |
記事番号29748へのコメント >索引を使った絞込みでは、該当行だけ調べることが期待できます。 目からフケがぼろぼろっと落ちました。(;_;) 索引=表と融合した並べ替え条件、という捉え方をしていたのですが 絞り込みを行うときにも影響があるとは想像出来ませんした。 しかし又何か勘違いしてるかもしれないので一つだけ確認したいのですが"この場合の索引"とは"やまだでんき"が 入力されている項目に設定する昇順とか降順とかの索引の事であっていますか? | |||
29761 | Re:索引のイメージが変わりました。 | うにん | 2005/04/27-13:31 |
記事番号29755へのコメント >索引=表と融合した並べ替え条件、という捉え方をしていたのですが >絞り込みを行うときにも影響があるとは想像出来ませんした。 実際にやってみたわけではないし、内部処理を知ってるわけでもないので、本当かどうかは?? 並べ替え条件を作らない索引定義もできるわけなので、検索や絞り込みにも影響あるはずです。 (検索の場合レコードを移動するだけなので顕著に影響しますが、 絞込みだと該当レコード群を全て抜き出すという処理が必要のために??) >"この場合の索引"とは"やまだでんき"が入力されている項目に設定する昇順 >とか降順とかの索引の事であっていますか? あってます。 既に絞りこんであったり、他の整列順になってる場合に有効かという点もやってみないとわかりませんね。 | |||
29769 | Re:索引のイメージが変わりました。 | しぼうかん | 2005/04/27-20:06 |
記事番号29761へのコメント 回答有り難うございました。 最初の投稿内容からは少しはずれてしまいましたが、 良い勉強になりました。 | |||
29774 | 【解説】索引と並べ替えに関して | 佐田 守弘 | 2005/04/27-21:16 |
記事番号29685へのコメント しぼうかんの#29755、#29761、#29769で、索引に関して触れておられます。 ちょうど良い機会なので、「索引とは何か?」、「索引と並べ替えの違い」について 解説をしておく事にします。 まず最初に述べておきますが、特に桐の場合、日本語で「索引」「並べ替え」という言葉でいうと、 索引とは並べ替えのために限定された機能の様に見えがちです。 しかし本来はデータベース一般でいう「インデックス機能」そのものです。 ●V5の整列索引との関係 従来から桐にはインデックス機能がありました(当然ですが)。そして桐ver.5までは整列ないし 整列索引と呼ばれていました。そしてこの時代の整列(索引)には、自動保守を「する」、「しない」の設定がありました。 この自動保守する索引は現在の「索引」に、自動保守しない整列は現在の「並べ替え」に引継がれました。 引継がれましたというよりも、機能は変わらずに呼び名だけが変わったと思って結構だと思います。 ●索引について 索引を定義すると、索引を作る条件(どの項目でどの順という条件)と共に、作られた索引データが表の中に書き込まれます。 索引の形式は確か、桐の仕様に「B-tree」と書かれていた様に記憶しますが、 具体的にどの様なものかは筆者はしりません(その道の専門家の解説に委ねます)。 索引を作ると、索引の対象となる項目値が、どうやらそのまま索引データの中に書き込まれる様です。 表のファイルサイズもその分だけ、大きくなります。 ●並べ替え条件と並べ替え 並べ替え条件も、定義する内容は索引と同じです。並べ替え条件を定義すると、 索引で言う索引を作る条件だけが定義として表に書き込まれます。 そして、その並べ替えを実行すると、索引の作成と同様に索引データが作られますが、 どうもワークエリアの様な所に作られるらしく、表には書き込まれません。そして作られた一時的な索引情報で並べ替えを行います。 他のDBは最近触っていないので良く分りませんが、昔の知識で言えば、Accessも五郎も、 並べ替えを行うと、テーブルのデータが実際に並べ替えられる仕様でした(今は知りません)。 しかし桐の並べ替えは、索引を使った並べ替えではその索引を使って、索引を使わない並べ替えの場合には 一時的に作られる臨時の索引で、見掛け上並べ替えて表示するだけです。 (解除すると元に戻ります) ●索引が利用される場合 索引と言うよりも、インデックスと言った方が分りやすいのがこの事です。 索引はあくまでも表の中から目的レコードを検索するのが目的のインデックスです。 並べ替えは、目的の順序でレコードを探しながら並べ替えるので、このインデックス機能が使われます。 その他に、検索、および表引き、併合でも目的レコードを検索しますから、利用できる索引があれば、それが使われます。 ●利用できる索引とは 索引は指定した項目の組合わせのデータで作られます。たとえば[社名]と[部署名]の索引を作ると、 「松桐産業渇c業部」といった様に対象となる項目値を組合わせたデータが索引に書き込まれるのだと思います。 [社名]と[部署名]で索引を作ってあるからといって、部署名での検索に使えるかというとそうではなく、 この索引は2番目の項目である部署名での検索には使えません。 検索する対象の項目値、表引きや併合でも同じですが、対象項目についての索引でないと、全く利用されません。 ●索引を作って有効な項目 検索するであろう可能性のある項目とその組合わせで索引を作っておけば、どれかが使われるかも知れませんが、非効率です。 検索対象(並べ替えでも表引き、併合でも同じ)となるメインの項目についての索引を作っておく事が総合的に有効です。 そしてその対象項目は、主キーとなれる様な、表のレコードを唯一に指定できる項目が有効です。 佐田守弘(KS-00119) | |||
29781 | Re:【解説】索引と並べ替えに関して | しぼうかん | 2005/04/28-21:00 |
記事番号29774へのコメント 佐田さんいつもの事ながら初心者にも非常に解りやすい説明ありがとうございました。 >索引を作ると、索引の対象となる項目値が、どうやらそのまま索引データの中に書き込まれる >様です。表のファイルサイズもその分だけ、大きくなります。 という事は「絞り込み」しか必要ない場合は整列しない索引とかが機能として有っても良い訳ですね。 まあ多分特殊な要望なのでそういう索引は搭載される事は無いんでしょうけど。 >[社名]と[部署名]で索引を作ってあるからといって、部署名での検索に使えるかというと >そうではなく、この索引は2番目の項目である部署名での検索には使えません。 ということは[社名]と[部署名]で索引1つを作り、[社名]=&社名,[部署名]=&部署名で 絞り込みをするより、[社名]と[部署名]それぞれの索引を作り[社名]=&社名, [部署名]=&部署名で絞り込む方が処理速度が速くなるということですよね? この処理速度の違いをはっきりと感じられるほどの大量レコードを扱うかどうかはわかりませんが、 データベースのしくみについての話は面白い話でした。 | |||
29783 | Re:【解説】索引と並べ替えに関して | うにん | 2005/04/29-09:54 |
記事番号29781へのコメント >という事は「絞り込み」しか必要ない場合は整列しない索引とかが >機能として有っても良い訳ですね。 >まあ多分特殊な要望なのでそういう索引は搭載される事は無いんでしょうけど。 一括処理の「索引定義」コマンドを見ればわかりますが、整列しない索引も作れます。 >ということは[社名]と[部署名]で索引1つを作り、[社名]=&社名,[部署名]=&部署名で >絞り込みをするより、[社名]と[部署名]それぞれの索引を作り[社名]=&社名, >[部署名]=&部署名で絞り込む方が処理速度が速くなるということですよね? それぞれの索引があっても、一度絞り込んだあとは索引が使えませんので? (#表引き関数のHELPに「表が絞り込み状態のときは、つねに索引は使用しません」とあるので多分間違いありません) しかし、どっちの索引を使った方が有利か自動的に判断してくれるかすかな可能性も??? 絞り込んだ行だけを対象にした索引が自動的に作られればいいのでしょうが、 そういうことは、してなさそう。 >この処理速度の違いをはっきりと感じられるほどの大量レコードを扱うかどうかは >わかりませんが、データベースのしくみについての話は面白い話でした。 実は私も大量レコードとはトンとご無沙汰なので... | |||
29786 | Re:【解説】索引と並べ替えに関して | 尾形 | 2005/04/29-15:56 |
記事番号29781へのコメント どうも、こんにちは >ということは[社名]と[部署名]で索引1つを作り、[社名]=&社名,[部署名]=&部署名で >絞り込みをするより、[社名]と[部署名]それぞれの索引を作り[社名]=&社名, >[部署名]=&部署名で絞り込む方が処理速度が速くなるということですよね? この部分だけ。 こういう時は [社名+部署名]を作成して 項目計算式に[社名]+[部署名]として [社名+部署名]で索引定義するのがよろしいかと 代入 &STR=&社名+&部署名 並べ替え 索引名="社名+部署名" 絞り込み [社名+部署名]{=&STR} パターン1 索引定義 索引名="社名部署名",{[社名],[部署名]} パターン2 索引定義 索引名="社名+部署名",{[社名+部署名]} パターン1は[部署名]までは索引効かないけど パターン2は[部署名]まで含んでいるので効果的だと思います | |||
29787 | Re:わかりやすい(つもり)方の説明です。 | 悲しげ | 2005/04/29-16:42 |
記事番号29746へのコメント 補完のNo.172を見て、やろうとしていることがようやく判りました。 確かにあの場合だと、絞り込みは無意味ですね。検索と違わないっつーか。(^^;) で、「一応希望どおりに出来ています」と云うことなので、 それはそれでよいのではないでしょうか? 細部は好みの問題ですし。 ただ、ひとつだけ気になったのは、編集表の切り替えを、 それぞれのフォーム開始時に取得した表番号で記述している点です。 フォームを開く順番とか、場合によっては桐が自動的に割り当てる 表番号の数字が動いてしまう危険性が無い訳でもないので、 編集表の切り替えは、表番号ではなく表ファイル名の方で記述した方が激しく無難なのではないかと思います。 もし、対象とする表ファイル名が可変なのであれば、文字列変数として、「名札 メイン」等で &請求伝票="請求伝票.tbl" のようにしておいた上で 編集表 &請求伝票 あるいは、表ファイル名が固定しているのであれば、単に 編集表 "請求伝票.tbl" だけの記述でよい訳で、こうしておけば表番号の挙動に神経を遣う必要もないので、却ってお気楽かと思います。 | |||
29792 | Re:Re:【解説】索引と並べ替えに関して | しぼうかん | 2005/04/29-22:51 |
記事番号29783へのコメント うにんさん、回答有り難うございます。 表定義の属性からしか索引を設定した事が無かったので 一括処理コマンドからの索引定義に限っては整列無しの 索引が設定出来るとは気が付きませんでした。 一括処理コマンドの索引のヘルプのパラメータを見ると <項目名> 昇順|降順|辞書順|辞書逆順,… } この"・・・"の部分、つまり何もパラメータをつけなければ 並べ替えをしない索引の事とは・・・。 >それぞれの索引があっても、一度絞り込んだあとは索引が使えませんので? 最初の絞り込み時には索引が有効で絞り込み後では無効になると言うことですね。 う〜ん素人的にはもし索引で索引を設定した項目の値が書き込まれているなら 絞り込み後にも使えても良さそうな気がしますが・・・そういう物として覚えて置きます。 | |||
29793 | Re:【解説】索引と並べ替えに関して | しぼうかん | 2005/04/29-22:53 |
記事番号29786へのコメント 尾形さん、返答有り難うございます。 >[社名+部署名]を作成して >項目計算式に[社名]+[部署名]として >[社名+部署名]で索引定義するのがよろしいかと 昔は[ほにゃ+らら]という項目が沢山ある表を作っていて 慣れてきてからは[ほにゃ+らら]のような項目を作るのは データベースの正統的では無いように思い、他の方法で代用できる場合は なるべく作らないようにしていますが、処理スピードを上げる場合には こういう方法も有効なんですね。 覚えておきます。 | |||
29794 | Re:わかりやすい(つもり)方の説明です。 | しぼうかん | 2005/04/29-23:05 |
記事番号29787へのコメント >フォームを開く順番とか、場合によっては桐が自動的に割り当てる >表番号の数字が動いてしまう危険性が無い訳でもないので、 げっ!そんな事があるとつゆしらず 手続き定義開始 フォーム::フォーム開始 &ほにゃらら=&表番号 ・・・ 手続き定義開始 何とか::マウス左クリック(・・・ ・・・ 編集表 &ほにゃらら ・・・ というような使い方は非常に多用していました。 フォームでの行挿入&行訂正モードで入力中に多重化フォームを使って 検索や絞り込みをする事が多いのでそれらの表と区別して使うのに 結構便利に使えるので何でも&表番号を代入して使う癖をつけてました。 入力中の表と"検索や絞り込みの作業用に使う入力中の表と同じ表を 多重化したフォームを併用する場合にはどうなのかまだ検証を していませんが、とりあえずそれ以外では安全の為教えて頂いた通りの &表番号を使わない方法に改める事にします。 汎用的で役に立つ知識ありがとうございました。 | |||
29795 | Re:Re:Re:【解説】索引と並べ替えに関して | 悲しげ | 2005/04/29-23:33 |
記事番号29792へのコメント 割り込みですが(^^;)、 >>それぞれの索引があっても、一度絞り込んだあとは索引が使えませんので? > >最初の絞り込み時には索引が有効で絞り込み後では無効になると言うことですね。 最初でも2段目でも、ともかく絞り込み時には索引は無効な筈ですよ。(^^;) うにんさんもそんなことは云ってないはずです。(「>>」引用部) | |||
29796 | Re:わかりやすい(つもり)方の説明です。 | 悲しげ | 2005/04/29-23:47 |
記事番号29794へのコメント >入力中の表と"検索や絞り込みの作業用に使う入力中の表と同じ表を >多重化したフォームを併用する場合にはどうなのかまだ検証を >していませんが、とりあえずそれ以外では安全の為教えて頂いた通りの >&表番号を使わない方法に改める事にします。 一般的には、フォームでは編集表の切り替えに際して、表番号よりも 表ファイル名ダイレクトの方が無難なことが多いことを書きましたが、 逆に、表ファイル名が使えず、表番号で対処するしか無い場合があります。 それは挙げられた多重化の場合。多重化表は表ファイル名が同じだからです。(^^;) (例) ・・・・ 変数宣言 自動,長整数{&表No1,&表No2} ・・・・ &表No1=#is表 /*多重化前の元表*/ 多重化 &表No2=#is表 /*多重化表*/ ・・・・ 終了 表 &表No2 /*多重化表を閉じる*/ 編集表 &表No1 /*編集表を元表に戻す*/ * 多重化表の表番号は、例えば &表No2=#表番号取得("hoge.tbl",2) のように取得する場合もあります。 | |||
29799 | 【解説】索引と並べ替え(2) | 佐田 守弘 | 2005/04/30-08:48 |
記事番号29793へのコメント しぼうかんさん #29793までを見ておりますと、まだ索引機能について一部あいまいな部分が ありそうに見えますので、改めて補足します。 なお、以下で「検索等」の表現をしますが、これは、検索、絞り込み、 表引き、併合などの処理で、データの検索を伴う処理を差します。 ●[社名]と[部署名]の索引 ・[社名]の索引:社名だけで検索等を行う時にのみ有効です。 ・[部署名]の索引:部署名だけで検索等を行う時にのみ有効です。 ・[社名+部署名]の索引:「○○梶「△部」の様に、社名部署名がつながった 言葉で検索等をする時に有効です。 社名だけでの検索等でも前方一致が有効かとは思いますが、確かめておりません。 以上までは宜しいでしょうか。 ●必要な索引だけを作っておく 索引は10個まで作れますから、様々な項目およびその組合わせで作れます。 しかし、不要な索引(検索等の頻度が低い)を作る事は、効率的ではありません。 索引を作ると、対象項目が索引情報として表に書かれます。 かつ、表を開く時に先に索引を読み込みますから、表を開くのに時間がかかります。 更に、索引を作っておくと、再定義の度に索引の再更正が行われるため、 再定義に時間が掛かります。 この様に便利なはずの索引が足かせになって、他の処理が遅くなる場合もあります。 従って、常時検索等を行う項目についてのみ、索引を作るのが正しい方法です。 ●絞り込み状態での索引 索引情報はあくまでも基本状態のデータに対してのものです。 絞り込み状態では基本状態とは、表の中味が異なります。 ですから、基本状態索引があっても、絞り込み状態になると、 その索引は意味を持ちません。 絞り込み状態になったら、「その状態で索引の再構成がされないのか?」という意味だと思います。 しかしそれは全く意味のない事と思います。 ・絞り込み状態 絞り込み状態を想定した索引は予め作れません(当然ですが)。 従って、絞り込み後に索引を作る事になるのでしょうが、索引を作る時間と 索引なしで検索する時間とどちらが早いかです。多分後者の方が早いから 一時的な索引を作る意味がないという事なのかと理解しています。 そして絞り込み毎に索引の更新をしてしまうと、解除する度に再び索引の 更新をするため、更に時間が掛かります。 ●大規模なデータでの大規模な索引 例えばこのBBSの過去ログを使って、[URL]、[タイトル]、[ハンドルネーム]のデータベースを作ったとします。 上記3つの項目で最もデータ量が多いのが[URL]でしょうか。しかも桐の場合半角でも1文字2バイトで処理されます。 この様な形のデータでレコード数は100万件を越え、ファイル総容量は索引なしで200MB以上に上るものを想像してみて下さい。 (実際に作っても意味がない事なので、想像だけに留めて下さい) これに[URL]についての索引を作ると、索引を作るだけでかなりの時間(10分位) が掛かり、ファイル容量は2倍近くに膨れ上がります。 ファイル容量が大きくなるという事は、バックアップありでは終了処理にも 書き込みに時間がかかる事になります。 さて、この様な膨大なデータでの索引による効果ですが、索引情報が大き過ぎるためか、 表を開いた時に索引を全て読み込めないらしく、最初の検索等の 処理では、索引があってもかなりの時間(分単位)が掛かります。 どうやら索引を読み込むのに時間がかかっている様なのですが、 その時間は索引なしで検索する場合に匹敵するほどの時間です。 ただし同じ検索等を繰り返すと、2回目からは高速になります。 佐田守弘(KS-00119) | |||
29814 | Re:わかりやすい(つもり)方の説明です。 | しぼうかん | 2005/05/01-00:00 |
記事番号29796へのコメント やはり多重化フォームでは使えませんでしたか、残念!。 多重化表をコード番号入力の為など頻繁に使う場合は 別フォーム&イベントファイルで最初に開いておいた方が イベント発生ごとに多重化するより良いのかな? と思い多重化コマンドを使おうとする事が無かったのですが、 &表No1=#is表 /*多重化前の元表*/ 多重化 &表No2=#is表 /*多重化表*/ &表No2=#表番号取得("hoge.tbl",2) これらの書き方で使うという事は知りませんでした。 頻繁に多重化表を使う場合以外はこの方が別フォーム& 別イベントファイルを作るよりずっと楽ですね。 | |||
29815 | Re:【解説】索引と並べ替え(2) | しぼうかん | 2005/05/01-00:05 |
記事番号29799へのコメント >●[社名]と[部署名]の索引 以下略・・・ >以上までは宜しいでしょうか。 はい。 >かつ、表を開く時に先に索引を読み込みますから、表を開くのに時間がかかり >ます。 今回勉強させて頂きました。 >絞り込み状態になったら、「その状態で索引の再構成がされないのか?」と >いう意味だと思います。しかしそれは全く意味のない事と思います。 全然違う事を考えていました。 お馬鹿なたとえ話で言うと索引を作るとその中に索引太郎君が常駐します。 索引太郎君は非常に頭が良くて索引項目の全データと索引順でのレコード位置を全て記憶しています。 索引を使った絞り込みを実行すると索引太郎君は絞り込むべきレコードの位置へ まっすぐに飛んでいき1レコードづつご主人様(操作する人)の所へ寄せ集めてきます。 というような想像をしていたので絞り込んだ状態でも索引太郎君の頭の中には 索引項目の全レコードのデータと位置情報が記憶されているので絞り込み後でも使えてもいいんじゃないの?と考えました。 しかし全く違っていたようです。(^^; >どうやら索引を読み込むのに時間がかかっている様なのですが、その時間は >索引なしで検索する場合に匹敵するほどの時間です。 >ただし同じ検索等を繰り返すと、2回目からは高速になります。 同じ検索を繰り返す場合以外は索引は前もって作って置かないとその効果を 実感しにくいと言う事ですね。 よくわかりまし | |||
29817 | Re:わかりやすい(つもり)方の説明です。 | 悲しげ | 2005/05/01-13:26 |
記事番号29814へのコメント >&表No2=#表番号取得("hoge.tbl",2) 誤解なきよう補足しておきますが、この方法で取得できる多重化表の表番号は、 あくまで2番目に多重化オープンした表のそれでして、 多重化3番目以降のそれではありません。 ですから、多重化表の表番号については、多重化オープンした順番や タイミングが問題でして、その辺は結構気を遣わなきゃならないのが辛いです。 この点は、フォームの編集表で多重化オープンする 表についても云えまして、その場合は確かに「フォーム開始」イベントの表番号で取得する方が妥当でしょうけど、 それでも当該フォームを開閉するタイミングはきっちり管理しておく必要があるように思えます。 ま、好みの問題に帰するのかもしれませんが、そんな訳で私はできれば 表番号を使わないで済ます方が多いです。 | |||
29819 | Re:Re:Re:【解説】索引と並べ替えに関して | 悲しげ | 2005/05/01-18:08 |
記事番号29795へのコメント >最初の絞り込み時には索引が有効で絞り込み後では無効になると言うことですね。 この文章の意味がようやく判りました。(^^;)(^^;) 私はここを、「最初(即ち1段目)絞り込みの後もまだ索引は有効で、 2段目絞り込みの後から索引が無効になる」のように誤読してしまっていました。 ここは正しくは「索引を利用できるのは、最初(即ち絞り込み前から)の絞り込み『時』だけであって、 絞り込み『後』は利用できない」の意味だったのですね。 失礼いたしました。<(_ _)> | |||
29820 | Re:わかりやすい(つもり)方の説明です。 | しぼうかん | 2005/05/01-23:53 |
記事番号29817へのコメント 了解しました。 |