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

研究会

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

〔581〕ACFinder 070318版 kabe (07/03/18 22:36)

〔613〕Re:070323test版 kabe (07/03/25 9:48)
〔614〕Re:070323test版 kabe (07/03/25 17:36)
〔615〕Re:070323test版 Hidemi Oya (07/03/25 21:43)
〔616〕Re:070323test版 Hidemi Oya (07/03/25 22:21)
〔617〕Re:070323test版 Hidemi Oya (07/03/25 22:38)
〔619〕Re:070323test版 Hidemi Oya (07/03/26 0:51)
〔621〕Re:070323test版 Hidemi Oya (07/03/26 23:16)
〔625〕Re:070323test版 kabe (07/03/27 9:40)
〔627〕Re:070323test版 kabe (07/03/27 21:13)
〔628〕Re:070323test版 kabe (07/03/27 21:15)
〔618〕Re:070323test版 Hidemi Oya (07/03/25 23:21)
〔620〕Re:070323test版 Hidemi Oya (07/03/26 22:11)
〔622〕Re:070323test版 Hidemi Oya (07/03/26 23:28)
〔626〕Re:070323test版 kabe (07/03/27 14:00)

〔613〕Re:070323test版
 kabe  (07/03/25 9:48)

引用なし
   >Hidemi Oyaさん

kabe です。

>tempsaku はおそらく大きなテーブルから regexp を使った作物検索をして作ってるんですよね?
そうです。SELECT DISTINCT して登録番号だけ抜き出してます。
リストボックスに表示する際はこの登録番号を含む薬剤を m_kihon から作成ています。

> 薬剤候補で検索したテンポラリテーブルを作成して、そこから作物検索をして通称タブや薬剤タブの一覧を取得するように変更すれば、速度はもっと改善できるのではないかと思います。
薬剤候補と作物候補の両方を指定した場合は、かなり速度改善の目処がたちました。
tekiyo テーブルで match を使うと、この部分がけっこう時間がかかるので、1回 m_kihon から検索対象薬剤を抜き出してからやるとけっこう早いです。
DROP TABLE IF EXISTS t_tmp0;
CREATE TEMP TABLE t_tmp0 AS SELECT bango FROM m_kihon WHERE meisho||shurui MATCH '%すみちおん%';
DROP TABLE IF EXISTS t_yaku;
CREATE TEMP TABLE t_yaku AS SELECT * FROM tekiyo WHERE bango IN t_tmp0;
DROP TABLE IF EXISTS t_bango;
CREATE TEMP TABLE t_bango AS SELECT DISTINCT bango FROM t_yaku WHERE sakumotsu REGEXP '(^|、|\()(なす.*?)(\)|、|$)' AND sakumotsu NOT REGEXP '\((.*、)?(なす.*?)(、.*)?を除く' ORDER BY bango

> また、テンポラリテーブルを使用する場合、vTekiyo と vTsushoTekiyo の参照元テーブルをテンポラリーテーブルにしてやれば、通称モードと商品名モードを切り替えるたびに再検索する必要がなくなります。
なるほど。
現在はデータベース更新の際にビューを作成していますが、検索するたびにテンポラリテーブルからテンポラリビューを作成すればよさそうですね。
こちらはまだ試してませんが、試行錯誤してみます。

〔614〕Re:070323test版
 kabe  (07/03/25 17:36)

引用なし
   kabe です。

>現在はデータベース更新の際にビューを作成していますが、検索するたびにテンポラリテーブルからテンポラリビューを作成すればよさそうですね。
>こちらはまだ試してませんが、試行錯誤してみます。
どうも、テンポラリテーブルはビューの参照元にできないみたいです。
まあ、一時的な実テーブルを作ってもよいので、作物検索結果を元にした標準、通称表示切り替えができるようにしたいと思います。

〔615〕Re:070323test版
 Hidemi Oya WEB  (07/03/25 21:43)

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

>どうも、テンポラリテーブルはビューの参照元にできないみたいです。
 確かに、テンポラリテーブルを参照元とするパーマネントビューは作れませんでした(^_^;)。が、テンポラリテーブルを参照元とするテンポラリビューは作れました。
 なお、一度作ったテンポラリビューは、参照元のテンポラリテーブルの内容が変更されても作り替える必要はありません。ただし、参照元のテンポラリテーブルが存在していない段階で、先にテンポラリビューを作成することはできません。

>まあ、一時的な実テーブルを作ってもよいので、作物検索結果を元にした標準、通称表示切り替えができるようにしたいと思います。
 ってことで、下記のような対応は可能です。クエリに毎回 CREATE TEMP VIEW が入ってしまうのが難点ですが、一時的な実テーブルを後で削除する必要はなくなります。

DROP TABLE IF EXISTS tTbl;
CREATE TEMP TABLE tTbl AS SELECT * FROM tekiyo WHERE sakumotsu REGEXP ...;
CREATE TEMP VIEW IF NOT EXISTS vTekiyo AS SELECT ... FROM tTbl;
CREATE TEMP VIEW IF NOT EXISTS vTsushoTekiyo AS SELECT ... FROM tTbl;
SELECT * FROM vTshushoTekiyo;

〔616〕Re:070323test版
 Hidemi Oya WEB  (07/03/25 22:21)

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

>クエリに毎回 CREATE TEMP VIEW が入ってしまうのが難点ですが、一時的な実テーブルを後で削除する必要はなくなります。
 ACFinder の終了時に作物タブ/病害虫タブで最後に実行した一時的な実テーブルを作成するための検索パラメータを保存しておき、次回起動時にそれを復元するとともに、前回最後に使った実テーブルを表示するってのであれば、実テーブルを使うのも結構良さそうです。
 検索パラメータもデータベースに保存しておけば、現在はデータ更新時にデータベースそのものを破棄しているので、自動的にパラメータや一時テーブルも破棄され、データ更新時に不都合も生じません。ただ、パーマネントテーブルが存在しない段階でパーマネントビューを作成することはできないので、いつビューを作成するかが問題です。結局、この方法でも毎回クエリに CREATE VIEW を入れなきゃですね。

 さらに、これをさらに推し進め、作物タブについては、作物とその時の検索結果を複数データベースに保存するようにしておけば、二度目以降は再検索の必要がないので、軽快に使えることになりますね。
 普及指導員が使用する場合、使う人によってよく使う作物はある程度決まってくるでしょうから、かなり有効な高速化手法ではないかと思います。といっても、これは将来的に対応可能であればということですが…。

〔617〕Re:070323test版
 Hidemi Oya WEB  (07/03/25 22:38)

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

>DROP TABLE IF EXISTS tTbl;
>CREATE TEMP TABLE tTbl AS SELECT * FROM tekiyo WHERE sakumotsu REGEXP ...;
>CREATE TEMP VIEW IF NOT EXISTS vTekiyo AS SELECT ... FROM tTbl;
>CREATE TEMP VIEW IF NOT EXISTS vTsushoTekiyo AS SELECT ... FROM tTbl;
>SELECT * FROM vTshushoTekiyo;
 テンポラリビューの使い方としてはこれで良いと思いますが、このテンポラリテーブルの作り方だと、近接作物を指定したときに再検索が必要になりますね。指定した主作物を対象作物とする農薬の全ての適用をテンポラリテーブルにして、病害虫一覧等を作成する際は毎回作物で検索するようにした方が良いかもしれません。

〔618〕Re:070323test版
 Hidemi Oya WEB  (07/03/25 23:21)

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

>クエリに毎回 CREATE TEMP VIEW が入ってしまうのが難点ですが
 ACFinder 起動時に、クエリ1のように定義だけで空のテンポラリテーブルを元に元にテンポラリビューを作成しておけば、操作時はクエリ2ですみますね。
 [#616]
>パーマネントテーブルが存在しない段階でパーマネントビューを作成することはできないので、いつビューを作成するかが問題です。
についても、これと同様に定義だけの一時テーブルを作成してパーマネントビューを作成しておけば OK ですね。

クエリ1
CREATE TEMP TABLE tTbl (...);
CREATE TEMP VIEW IF NOT EXISTS vTekiyo AS SELECT ... FROM tTbl;
CREATE TEMP VIEW IF NOT EXISTS vTsushoTekiyo AS SELECT ... FROM tTbl;

クエリ2
DROP TABLE IF EXISTS tTbl;
CREATE TEMP TABLE tTbl AS SELECT * FROM tekiyo WHERE sakumotsu REGEXP ...;
SELECT * FROM vTshushoTekiyo;

〔619〕Re:070323test版
 Hidemi Oya WEB  (07/03/26 0:51)

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

> 指定した主作物を対象作物とする農薬の全ての適用をテンポラリテーブルにして、病害虫一覧等を作成する際は毎回作物で検索するようにした方が良いかもしれません。
 クエリ1(テンポラリビューは [#618] の方法で作成済み)で試してみました。が、この方法で病害虫一覧等も作成するとなるとさすがに時間がかかり、大きな速度改善効果は期待できません。
 近接作物を指定したときは多少遅くなりますが、クエリ2の方が良さそうです。なお、この場合絞り込み条件の病害虫一覧等は tSaku から生成します。また、絞り込み条件が指定されている場合は、tTmp を作成する際に WHERE 節を付加します。

クエリ1
CREATE TEMP TABLE tBango AS
SELECT DISTINCT bango FROM m_tekiyo WHERE sakumotsu REGEXP ...;
DROP TABLE IF EXISTS tTbl;
CREATE TEMP TABLE tTbl AS
SELECT * FROM tekiyo WHERE bango in (SELECT bango FROM tBango);
DROP TABLE tBango;
SELECT * FROM tvTsushoTekiyo WHERE sakumotsu REGEXP ...;

クエリ2
DROP TABLE IF EXISTS tSaku;
CREATE TEMP TABLE tSaku AS SELECT * FROM tekiyo WHERE 主作物検索条件;
DROP TABLE IF EXISTS tTbl;
(1) 近接作物が指定されていない場合
CREATE TEMP TABLE tTbl AS SELECT * FROM tSaku;
(2) 近接作物が指定されている場合
CREATE TEMP TABLE tTmp AS SELECT DISTINCT bango FROM tSaku;
CREATE TEMP TABLE tTbl AS SELECT * FROM tekiyo
WHERE bango IN (SELECT bango FROM tTmp)
AND ((主作物検索条件) OR (近接作物検索条件));
DROP TABLE tTmp;
(3) (1), (2) 共通
SELECT * FROM tvTsushoTekiyo;

〔620〕Re:070323test版
 Hidemi Oya WEB  (07/03/26 22:11)

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

>薬剤候補と作物候補の両方を指定した場合は、かなり速度改善の目処がたちました。
 薬剤候補のみ指定した場合は現状で十分高速なので、問題は「作物候補のみを指定した場合」ということでしょうか?
 作物からの検索は作物タブがあるので(こいつの高速化はかなり難しいですが、[#619] の方法でかなり改善はできます)、薬剤タブの基本はまず薬剤候補を指定することだと思います。なので、作物候補のみを指定した場合の検索速度は、あまり気にする必要はないかと…。

 ところで、ACFinder って、ストリンググリッドの表示に結構時間がかかりますね。自前テストソフトだと1秒で表示できるテーブルが、ACFinder だと 2.1 秒かかります。これって、セル幅のオートアジャストに時間がかかっているのでしょうか?
 オートアジャストに時間がかかっているのならやむを得ませんが、もしストリンググリッドの ColCount, RowCount プロパティを結果をセットする前に設定していないなら、下記のように設定することで行数の多い表なら表示速度を改善できる可能性があります(薬剤タブのように行数が少ない表はほとんど変わりません)。

tb := DB.GetTable(SQL);
StringGrid1.ColCount := tb.ColCount;
StringGrid2.RowCount := tb.RowCount + 1; // +1 はヘッダ表示用

〔621〕Re:070323test版
 Hidemi Oya WEB  (07/03/26 23:16)

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

 [#619] のクエリ2ですが、ACFinder 起動時に次のようなテンポラリテーブルを作成すると、さらに高速化が可能です。作物に「ブロッコリー,あぶらな科野菜,野菜類」を指定した場合、自宅マシンで [#619] のクエリ2が初回 2.3 秒ですが、下記のクエリなら初回 1.8 秒です。
 なお、テンポラリテーブルの作成は自宅マシンで 1.3 秒、パーマネントテーブルとして作成しても同じ時間でした。この程度なら ACFinder 起動時にテンポラリテーブルとして毎回作成しても苦にはならないですが、薬剤タブでも使うなら、データ更新時にパーマネントテーブルとして作成した方が良いかもしれません。

--ACFinder 起動時
CREATE TEMP TABLE tsTekiyo (...);
CREATE TEMP VIEW IF NOT EXISTS tvTekiyo AS
SELECT ... FROM tsTekiyo;
CREATE TEMP VIEW IF NOT EXISTS tvTsushoTekiyo AS
SELECT ... FROM tsTekiyo;
--追加テンポラリテーブル作成
CREATE TEMP TABLE tBangoSaku AS
SELECT DISTINCT bango, sakumotsu FROM tekiyo;

--作物タブ用クエリ
CREATE TEMP TABLE tTmp AS SELECT bango FROM tBangoSaku WHERE 作物検索条件;
DROP TABLE IF EXISTS tSaku;
CREATE TEMP TABLE tSaku AS SELECT * FROM tekiyo
WHERE bango IN tTmp AND 作物検索条件;
DROP TABLE tTmp;
DROP TABLE IF EXISTS tsTekiyo;
--(1) 近接作物指定無し
CREATE TEMP TABLE tsTekiyo AS SELECT * FROM tSaku;
/*
--(2) 近接作物指定有り
CREATE TEMP TABLE tTmp AS SELECT DISTINCT bango FROM tSaku;
CREATE TEMP TABLE tsTekiyo AS SELECT * FROM tekiyo
WHERE (bango IN tTmp) AND ((作物検索条件) OR (近接作物検索条件));
DROP TABLE tTmp;
*/
--(3) 適用表示
SELECT * FROM tvTsushoTekiyo;

〔622〕Re:070323test版
 Hidemi Oya WEB  (07/03/26 23:28)

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

> ところで、ACFinder って、ストリンググリッドの表示に結構時間がかかりますね。自前テストソフトだと1秒で表示できるテーブルが、ACFinder だと 2.1 秒かかります。これって、セル幅のオートアジャストに時間がかかっているのでしょうか?
 ACFinder は結果表示用のストリンググリッドを毎回ダイナミックに生成していますが、各タブにスタティックにストリンググリッドを貼り付けておいて、それを使い回して方が表示が高速になるかも…。

〔625〕Re:070323test版
 kabe  (07/03/27 9:40)

引用なし
   >Hidemi Oyaさん

kabe です。

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

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

作物コードをデータ更新時に同時に作成することになるので、データ更新時間がどれくらい増えるかですね。

〔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 の時点で先に必要なセル幅とデータが存在しないフィールドを調べておいた方が早いのかもしれません。
検索機能の見直しが一段落したら、この部分改善してみます。

グリッドコンポーネントはもっといいものがないかと探しているのですが、シェアウェアだと高機能なものがありますが、フリーではなかなか理想とする機能が全て入っているものがみつかりません。

〔627〕Re:070323test版
 kabe  (07/03/27 21:13)

引用なし
   kabe です。

>作物コードをデータ更新時に同時に作成することになるので、データ更新時間がどれくらい増えるかですね。
実験中です。
m_kihon の9万行のレコードの 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 にインデックス設定を行った上です。

〔628〕Re:070323test版
 kabe  (07/03/27 21:15)

引用なし
   kabe です。

>m_kihon の9万行のレコードの
訂正↑m_tekiyo です。

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