Laboratory of Mobile Agricultural Chemicals Searcher
携帯農薬検索実験室

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
22 / 54 ﾍﾟｰｼﾞ <前へ | 次へ>
〔643〕Re:070329test版
 Hidemi Oya WEB  (07/04/01 0:29)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>　作物タブに比べると、わずかにもたつき感があるような気がします。
　これは、m_tekiyo の idbyochu のインデックスである idxIdByochu が作成されてないのが原因のようです。idxIdByochu を作成すると、速くなりました。
　なお、PRIMARY KEY や UNIQUE を付与したフィールドには自動的にインデックスが作成されるので、idxMByochu や idxMSaku は作成しなくても良さそうです。これらを削除して試してみましたが、検索時間は変わりませんでした。

　ちなみに、下記のように複数のフィールドを指定できるようになっていますが、これだと idsaku に対する検索速度向上効果はありますが、idbyochu に対する効果はありません。文法的には許容されてるけど、最初に指定したフィールドしかインデックスを作成しないような実装になってるんですかねえ？
create index idxIdMTekiyo on m_tekiyo (idsaku, idbyochu);
・ツリー全体表示
〔642〕Re:070329test版
 Hidemi Oya WEB  (07/03/30 0:06)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>データ更新時の処理が増えたため073028test版よりやや時間がかかります。
　自宅マシンでは、30 秒強で、070328test 版とほとんど変わりませんでした。実は、070328test 版で m_byochu を作るのに 0.8 秒、m_tekiyo2 を作るのに 4.7 秒程度だったので、070328test 版より２秒弱遅くなると踏んでたんですが…。
　SQLite.pas は UTF-16 より UTF-8 の方が効率がよいので、エンコーディングを UTF-8 に変更したのが効いているのかもしれませんね。
　また、データベースサイズも 30 ％増しは覚悟してたんですが、思ったより小さかったです。

> 検索速度が向上しているはずです。
　作物タブに比べると、わずかにもたつき感があるような気がします。「あざみうま」とか「あぶらむし」とかレコード数が多い(表示に時間がかかる)病害虫を指定したせいでしょうか…。


-- m_byochu 作成
-- idbyochu, byochu は自動的にインデックスが作成される
CREATE TABLE m_byochu (idbyochu INTEGER PRIMARY KEY AUTOINCREMENT, byochu VARCHAR UNIQUE);
INSERT INTO m_byochu (byochu) SELECT DISTINCT byochu FROM m_tekiyo ORDER BY byochu;

-- mtekiyo2 作成
CREATE TABLE m_tekiyo2 AS
SELECT ... FROM m_tekiyo AS a
LEFT JOIN m_sakumotsu ON a.sakumotsu = m_sakumotsu.sakumotsu
LEFT JOIN m_byochu ON a.byochu = m_byochu.byochu;
・ツリー全体表示
〔641〕070329test版
 kabe  (07/03/29 23:15)
引用なし
   kabe です。

070329test版です。
exeのみです。
http://acfinder.kabe.info/acfinder070329test.zip

テーブルの構成を変更したためデータ更新が必須です。
データ更新時の処理が増えたため073028test版よりやや時間がかかります。

[#639]病害虫名マスターを作成し、病害虫タブの検索に利用しています。
検索速度が向上しているはずです。

[#636]データベースの文字コードを UTF-8 に変更しました。
データベース更新すると反映されます。

>登録番号と有効成分だけの実テーブル m_seibun を作成したいと思います。
従来の kihon テーブルを廃止し m_seibun を作成するようにしました。
bango,ippanmei,seibun,node フィールドを持ちます。
・ツリー全体表示
〔640〕Re:UTF-16le の ORDER BY
 kabe  (07/03/29 10:13)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　前からおかしいと思いつつそのままにしてあったんですが、改めて確認してみたら、やはり UTF-16le の場合、日本語を含む文字列の ORDER BY がちゃんと機能していませんね。
私も変だなとは思ってましたが、仕様なのかと思ってそのままにしてました。

>　ってことで、今更ながらですが、データベースのエンコーディングは UTF-8 の方が良さそうです。UTF-8 だとデータベースサイズが大きくなってしまいますが、kihon はテンポラリテーブルとして作成して m_kihon だけデータベースに保存するようにすれば、若干データベースサイズを削減できるのでは？
了解しました。UTF-8 に変更します。
kihon テーブルの方は現状では薬剤タブの同一成分の薬剤を表示する部分で使っており、登録番号と有効成分だけの実テーブル m_seibun を作成したいと思います。
・ツリー全体表示
〔639〕Re:m_byochu も作りますか？
 kabe  (07/03/29 10:07)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>病害虫タブでも、作物タブ同様に m_byochu テーブルを作って病害虫の検索をしますかねえ？
>　m_tekiyo に病害虫コードを追加しなければならないので、データベース更新がまた遅くなると困りますが…。
これは、どうしようかなと思ってました。
UPDATE で更新するには、データ更新時間が増えるだけなので、やめようと思ってたのですが、070328test版の方法だと環境によってはそれほど変わらないというのであれば、作物名マスター、病害虫名マスターの両方を持ってもいいですね。
レコード数は３月２０日登録データで1384件なので、作物名テーブルを作成するのとほぼ同じ時間がかかると思われます。
検索速度という点では効果が大きいので、テスト版を作成してみます。


>　それと、tv_Tekiyo と tv_TsushoTekiyo は作物タブと病害虫タブの両方で使い、内容が毎回変わるわけではないので、[#618] に書いたような方法で ACFinder 起動時に作成しておいて、検索のたびに作成するのはやめませんか？
これは無駄なので起動時に作成するように修正します。
ただ作物タブと病害虫タブのビューの参照元はそれぞれタブ専用の検索結果を格納するテーブルを作成しています。よってビューもタブごとに分けています。
・ツリー全体表示
〔638〕m_byochu も作りますか？
 Hidemi Oya WEB  (07/03/29 0:29)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>不思議なことにグリッドの表示部分は全くいじってないのですが、その部分も含めて体感的に早くなった感じがします。
　そうそう。表示部分も改良したのかと思ってました。

>９万行以上のデータに対して REGEXP で検索する負荷がかなり高かったかもしれません。
　SQLite は、ちゃんと論理式のショートカット評価を行っているようで、各行で必ず regexp が実行される
sakumotsu regexp ... and zaikei in (...);
と、in の結果が偽なら regexp は実行されない
zaikei in (...) and sakumotsu regexp ...;
では検索速度が結構違います。逆に言うと、in 演算子と比べても regexp はかなり遅いということになります。
　ちなみに、定型処理テンプレートでは、用途や剤型など in 演算子で検索する条件を先に評価するようにして、なるべく検索が速くなるように変更しました。

　ところで、作物タブと薬剤タブが爆速になったので、決して遅くはない病害虫タブが遅く感じられるようになりました(^_^;)。病害虫タブでも、作物タブ同様に m_byochu テーブルを作って病害虫の検索をしますかねえ？
　m_tekiyo に病害虫コードを追加しなければならないので、データベース更新がまた遅くなると困りますが…。

　それと、tv_Tekiyo と tv_TsushoTekiyo は作物タブと病害虫タブの両方で使い、内容が毎回変わるわけではないので、[#618] に書いたような方法で ACFinder 起動時に作成しておいて、検索のたびに作成するのはやめませんか？
・ツリー全体表示
〔637〕Re:070328test版
 Hidemi Oya WEB  (07/03/28 22:57)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>若干、データ更新時間が短くなります。
　自宅マシンではデータベース更新が 30 秒で、以前とあまり変わらないほどに改善しました。テンポラリ m_tekiyo 作成時に完全にメモリ内で処理可能か、あるいはスワップが発生するか、メモリ搭載容量によって効果の度合いが違うのかもしれません。

>[#612]SQLタブのクエリ埋め込み開発者モードに対応しました。
　ありがとうございます。--/d 対応の複数作物系テンプレートと、m_sakumotsu 対応の特定作物系テンプレートを近々公開したいと思います。
・ツリー全体表示
〔636〕UTF-16le の ORDER BY
 Hidemi Oya WEB  (07/03/28 22:40)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　前からおかしいと思いつつそのままにしてあったんですが、改めて確認してみたら、やはり UTF-16le の場合、日本語を含む文字列の ORDER BY がちゃんと機能していませんね。UTF-8 は OK なので、sqlite の内部ソート関数がきっちり UTF-16le に対応できていないのではないかという感じがします(UTF-8 と同じ関数を UTF-16le でも使っているとか)。
　ってことで、今更ながらですが、データベースのエンコーディングは UTF-8 の方が良さそうです。UTF-8 だとデータベースサイズが大きくなってしまいますが、kihon はテンポラリテーブルとして作成して m_kihon だけデータベースに保存するようにすれば、若干データベースサイズを削減できるのでは？
・ツリー全体表示
〔635〕070328test版
 kabe  (07/03/28 22:31)
引用なし
   kabe です。

070328test版です。
exeのみです。
http://acfinder.kabe.info/acfinder070328test.zip

>　ってことは、従来の m_tekiyo をテンポラリテーブルとして作成して、そこから m_sakumotsu を生成、テンポラリ m_tekiyo と m_sakumotsu を JOIN してパーマネント m_sakumotsu を作成すれば、UPDATE の半分の時間で同じテーブルが作れることになります。
この方法でデータ更新を行ってみました。
若干、データ更新時間が短くなります。

[#612]SQLタブのクエリ埋め込み開発者モードに対応しました。
・ツリー全体表示
〔634〕Re:070327test版
 kabe  (07/03/28 8:52)
引用なし
   kabe です。

配布されているメモリー256MBの VersaPro でも作物検索が軽快に行えます。
不思議なことにグリッドの表示部分は全くいじってないのですが、その部分も含めて体感的に早くなった感じがします。
以前はグリッドに表示される前に、かなりディスクアクセスがあって、表示が待たされる感じだったんですが、これがかなり少なくなりました。
９万行以上のデータに対して REGEXP で検索する負荷がかなり高かったかもしれません。

「移植水稲」など検索結果が多いものはそれなりに時間がかかりますが...
・ツリー全体表示
〔633〕Re:070327test版
 Hidemi Oya WEB  (07/03/28 1:56)
引用なし
   >　しかし、なんで UPDATE はこんなに遅いのか…。
　自宅マシンで UPDATE にかかる時間は 8.2 秒でした。で、下記のような方法で作物コードを付加したテーブルを作った場合は、4.0 秒です。
　ってことは、従来の m_tekiyo をテンポラリテーブルとして作成して、そこから m_sakumotsu を生成、テンポラリ m_tekiyo と m_sakumotsu を JOIN してパーマネント m_sakumotsu を作成すれば、UPDATE の半分の時間で同じテーブルが作れることになります。

CREATE TABLE m_tekiyo2 AS
SELECT ..., m_sakumotsu.idsaku AS sakuid FROM m_tekiyo
LEFT JOIN m_sakumotsu ON m_tekiyo.sakumotsu = m_sakumotsu.sakumotsu
・ツリー全体表示
〔632〕Re:070327test版
 Hidemi Oya WEB  (07/03/28 1:00)
引用なし
   >m_kihon の定義段階で idsaku を作っておき、m_sakumotsu 作成後に、REPLACE INTO で idsaku に作物コードを設定すれば、UPDATE より速いかなあ？
　UPDATE をするのに、当然 idsaku は最初から作ってありますね。で、REPLACE INTO は行単位でしか書き換えられないので、UPDATE の方が速そうです。
　しかし、なんで UPDATE はこんなに遅いのか…。
・ツリー全体表示
〔631〕Re:070327test版
 Hidemi Oya WEB  (07/03/28 0:44)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>[#625]の方法で作物タブでの作物名検索方法を見直しました。
　データベース更新時間が、自宅マシンで約 29 秒だったのが約 35 秒と約 20 ％増でした。[#267] の事例も考えると、マシンにはよるけど 20〜30 ％増というところでしょうか…。070311 版で速度アップした分に、おまけを付けて遅くなってしまいました(^_^;)。
　自宅マシンの 35 秒は十分許容範囲ですが、事務所マシンだとちょっとつらいかも…。

　070327test 22:25 版の「ブロッコリー,あぶらな科野菜,野菜類」検索のログを SQL タブにコピーして実行すると、適用の表示が完了するまでにわずか 0.8 秒。体感的には、以前の爆速レベルに戻ったといえます。近接作物を指定しても、十分満足できる速度です。

　ただ、できればデータベース更新速度は落としたくないところ。テーブルを作り替えるのではなく、idsaku を m_sakumotsu から JOIN したビューならどうかなと思って、tekiyo の a.idsaku AS idsaku を m_sakumotsu.idsaku AS idsaku に変更して、最後に
LEFT JOIN m_sakumotsu ON a.sakumotsu = m_sakumotsu.sakumotsu
を追加した tekiyo2 を作って試してみましたが、残念ながら [#621] より遅かったりします(^_^;)。
　UPDATE を使わずに、m_kihon を作る段階で作物コードを付与できる良い方法があればねえ…。m_kihon の定義段階で idsaku を作っておき、m_sakumotsu 作成後に、REPLACE INTO で idsaku に作物コードを設定すれば、UPDATE より速いかなあ？
・ツリー全体表示
〔630〕Re:070327test版
 kabe  (07/03/27 22:34)
引用なし
   kabe です。

適用データ(m_tekiyo)側の作物コードにインデックスを設定するのを忘れました。
今しがたアーカイブファイルを更新しました。
acfinder.exe のタイムスタンプが 22:25なら最新版です。
・ツリー全体表示
〔629〕070327test版
 kabe  (07/03/27 22:07)
引用なし
   kabe です。

070327test版です。
exeのみです。
http://acfinder.kabe.info/acfinder070327test.zip

[#625]の方法で作物タブでの作物名検索方法を見直しました。
体感的にもけっこう早くなっています。

ただし、今回からテーブルを修正したため、データベース更新が必須です。
データベース更新時間は今までよりもかかります。
一応メッセージが出るようにしていますが、出なかった場合は手動でデータベース更新を実行してください。
・ツリー全体表示
〔628〕Re:070323test版
 kabe  (07/03/27 21:15)
引用なし
   kabe です。

>m_kihon の９万行のレコードの
訂正↑m_tekiyo です。
・ツリー全体表示
〔627〕Re:070323test版
 kabe  (07/03/27 21:13)
引用なし
   kabe です。

>作物コードをデータ更新時に同時に作成することになるので、データ更新時間がどれくらい増えるかですね。
実験中です。
m_kihon の９万行のレコードの UPDATE 処理を加えた場合のデータ更新時間は、私の環境で今まで 50秒程度が70秒以上かかります。
UPDATE m_tekiyo SET idsaku = (
SELECT idsaku FROM m_sakumotsu
WHERE m_sakumotsu.sakumotsu m_tekiyo.sakumotsu)
m_sakumotsu の sakumotsu と　m_tekiyoのsakumotsu にインデックス設定を行った上です。
・ツリー全体表示
〔626〕Re:070323test版
 kabe  (07/03/27 14:00)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　ところで、ACFinder って、ストリンググリッドの表示に結構時間がかかりますね。
そうですね。SQL検索は終わってから表示が完了するまでは、データ量が多いと、時間がかかる部分です。

>StringGrid1.ColCount := tb.ColCount;
>StringGrid2.RowCount := tb.RowCount + 1; // +1 はヘッダ表示用
これは設定しています。

表示幅の自動設定は全てのセルを調べてから、各列幅を設定し、その後に表示幅ゼロ（データが存在しないフィールド）の列を削除しています。
現在は StringGrid にデータをセットした後で調べてますが、GetTable の時点で先に必要なセル幅とデータが存在しないフィールドを調べておいた方が早いのかもしれません。
検索機能の見直しが一段落したら、この部分改善してみます。

グリッドコンポーネントはもっといいものがないかと探しているのですが、シェアウェアだと高機能なものがありますが、フリーではなかなか理想とする機能が全て入っているものがみつかりません。
・ツリー全体表示
〔625〕Re:070323test版
 kabe  (07/03/27 9:40)
引用なし
   ＞Hidemi Oyaさん

kabe です。

作物名そのものを REGEXP で検索する時間をどれくらい短縮できるかですね。
この考え方をさらに進めると、次の方法が効果的と思われます。

作物名を単一化して作物コードと作物名のみのテーブルを作成する。
m_tekiyo テーブルに作物コードを付加して、作物名テーブルから作物コードを更新する。
作物検索は最初に作物名テーブルで検索して、作物コードを抽出してから適用を検索する。
これだと REGEXP での作物名検索は現状で 1100レコード程度に対して行えば済むのでかなり高速化が期待できそうです。

作物コードをデータ更新時に同時に作成することになるので、データ更新時間がどれくらい増えるかですね。
・ツリー全体表示
〔624〕Re:070326test版
 kabe  (07/03/27 0:14)
引用なし
   kabe です。

病害虫タブでは、病害虫を指定した最初の検索速度は変わりませんが、一度検索した後の、作物絞り込み、標準・通称モード切替は早くなっています。

なお、近接作物を指定した場合、病害虫リストには、主作物には存在しない、近接作物の病害虫名も入ります。（使用目的、用途、剤型も同様）
リスト作成時に主作物で絞り込めばいいのですが、ここはこのままの仕様でもいいのかなと思っていますが、いかがでしょう。

その他、基本設定の接続タブに設定項目を追加しています。
（Hidemi Oya さんの InetUtilコンポーネント新版を適用しています）
インターネットエクスプローラ側でオフライン作業に設定されている状態で ACFinderをオンライン状態で起動した場合に、Windows側の設定を強制的にオンラインに変更できます。
・ツリー全体表示
  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
22 / 54 ﾍﾟｰｼﾞ <前へ | 次へ>
ページ：  ┃  記事番号：   
(SS)C-BOARD vv3.8 is Free.