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

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
48 / 114 ツリー <前へ | 次へ>

〔623〕070326test版 kabe (07/03/27 0:01)

〔629〕070327test版 kabe (07/03/27 22:07)
〔630〕Re:070327test版 kabe (07/03/27 22:34)
〔631〕Re:070327test版 Hidemi Oya (07/03/28 0:44)
〔632〕Re:070327test版 Hidemi Oya (07/03/28 1:00)
〔633〕Re:070327test版 Hidemi Oya (07/03/28 1:56)
〔635〕070328test版 kabe (07/03/28 22:31)
〔637〕Re:070328test版 Hidemi Oya (07/03/28 22:57)
〔634〕Re:070327test版 kabe (07/03/28 8:52)
〔638〕m_byochu も作りますか? Hidemi Oya (07/03/29 0:29)
〔639〕Re:m_byochu も作りますか? kabe (07/03/29 10:07)
〔636〕UTF-16le の ORDER BY Hidemi Oya (07/03/28 22:40)
〔640〕Re:UTF-16le の ORDER BY kabe (07/03/29 10:13)
〔641〕070329test版 kabe (07/03/29 23:15)
〔642〕Re:070329test版 Hidemi Oya (07/03/30 0:06)
〔643〕Re:070329test版 Hidemi Oya (07/04/01 0:29)
〔644〕070328test版以降用テンプレート Hidemi Oya (07/04/01 1:02)

〔629〕070327test版
 kabe  (07/03/27 22:07)

引用なし
   kabe です。

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

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

ただし、今回からテーブルを修正したため、データベース更新が必須です。
データベース更新時間は今までよりもかかります。
一応メッセージが出るようにしていますが、出なかった場合は手動でデータベース更新を実行してください。

〔630〕Re:070327test版
 kabe  (07/03/27 22:34)

引用なし
   kabe です。

適用データ(m_tekiyo)側の作物コードにインデックスを設定するのを忘れました。
今しがたアーカイブファイルを更新しました。
acfinder.exe のタイムスタンプが 22:25なら最新版です。

〔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 より速いかなあ?

〔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 はこんなに遅いのか…。

〔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

〔634〕Re:070327test版
 kabe  (07/03/28 8:52)

引用なし
   kabe です。

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

「移植水稲」など検索結果が多いものはそれなりに時間がかかりますが...

〔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タブのクエリ埋め込み開発者モードに対応しました。

〔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 だけデータベースに保存するようにすれば、若干データベースサイズを削減できるのでは?

〔637〕Re:070328test版
 Hidemi Oya WEB  (07/03/28 22:57)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

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

>[#612]SQLタブのクエリ埋め込み開発者モードに対応しました。
 ありがとうございます。--/d 対応の複数作物系テンプレートと、m_sakumotsu 対応の特定作物系テンプレートを近々公開したいと思います。

〔638〕m_byochu も作りますか?
 Hidemi Oya WEB  (07/03/29 0:29)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

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

>9万行以上のデータに対して 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 起動時に作成しておいて、検索のたびに作成するのはやめませんか?

〔639〕Re:m_byochu も作りますか?
 kabe  (07/03/29 10:07)

引用なし
   >Hidemi Oyaさん

kabe です。

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


> それと、tv_Tekiyo と tv_TsushoTekiyo は作物タブと病害虫タブの両方で使い、内容が毎回変わるわけではないので、[#618] に書いたような方法で ACFinder 起動時に作成しておいて、検索のたびに作成するのはやめませんか?
これは無駄なので起動時に作成するように修正します。
ただ作物タブと病害虫タブのビューの参照元はそれぞれタブ専用の検索結果を格納するテーブルを作成しています。よってビューもタブごとに分けています。

〔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 を作成したいと思います。

〔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 フィールドを持ちます。

〔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 版より2秒弱遅くなると踏んでたんですが…。
 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;

〔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);

〔644〕070328test版以降用テンプレート
 Hidemi Oya WEB  (07/04/01 1:02)

引用なし
    ACFinder 070328test 版以降で使用できるテンプレートを公開しました。[#610] の template070324.zip は削除したため、今回もフルセットとなっています。
 主な変更点は下記の通りです。クロス表を作成しているとは思えないほど速いです。

  1. 各テンプレートで作物検索に m_sakumotsu テーブルを使用することにより、検索速度を向上
  2. 複数作物系テンプレートでクエリ埋め込み開発者モードに対応


template070331.zip


  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
48 / 114 ツリー <前へ | 次へ>
ページ:  ┃  記事番号:   
(SS)C-BOARD vv3.8 is Free.