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

研究会

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

〔327〕ACFinder 060620版 kabe (06/06/20 23:21)
〔332〕Re:ACFinder 060620版 Hidemi Oya (06/06/21 16:06)
〔333〕SQL ステートメント制限 Hidemi Oya (06/06/22 11:45)
〔335〕Re:SQL ステートメント制限 kabe (06/06/22 22:46)
〔337〕正規表現拡張構文 Hidemi Oya (06/06/23 0:56)
〔338〕Re:正規表現拡張構文 Hidemi Oya (06/06/23 13:31)
〔341〕Re:SQL ステートメント制限 s_kobayashi (06/06/23 22:02)
〔342〕「キング」対応パターン Hidemi Oya (06/06/24 0:05)
〔343〕テーブルの構成 kabe (06/06/24 1:03)
〔346〕Re:テーブルの構成 Hidemi Oya (06/06/24 12:04)
〔347〕Re:テーブルの構成 kabe (06/06/24 17:24)
〔348〕Re:テーブルの構成 Hidemi Oya (06/06/24 21:56)
〔349〕Re:テーブルの構成 kabe (06/06/24 22:29)
〔350〕Re:テーブルの構成 Hidemi Oya (06/06/25 3:04)
〔352〕Re:テーブルの構成 kabe (06/06/25 15:03)
〔354〕Excel 読み込み高速化 Hidemi Oya (06/06/25 16:35)
〔355〕Re:テーブルの構成 kabe (06/06/25 16:48)
〔356〕Re:テーブルの構成 Hidemi Oya (06/06/25 18:28)
〔357〕Re:テーブルの構成 kabe (06/06/25 21:25)
〔358〕Re:テーブルの構成 Hidemi Oya (06/06/25 22:41)
〔359〕Re:テーブルの構成 Hidemi Oya (06/06/25 23:17)
〔360〕Re:テーブルの構成 kabe (06/06/26 7:03)
〔361〕Re:テーブルの構成 Hidemi Oya (06/06/26 20:53)
〔351〕Re:テーブルの構成 kabe (06/06/25 14:24)
〔353〕Re:テーブルの構成 Hidemi Oya (06/06/25 15:53)
〔344〕Re:「キング」対応パターン s_kobayashi (06/06/24 8:42)
〔345〕Re:「キング」対応パターン Hidemi Oya (06/06/24 10:58)
〔334〕ACFinder 060622版 kabe (06/06/22 22:22)
〔336〕Re:ACFinder 060622版 Hidemi Oya (06/06/23 0:04)
〔339〕Re:ACFinder 060622版 kabe (06/06/23 19:46)
〔340〕Re:ACFinder 060622版 Hidemi Oya (06/06/23 20:02)

〔327〕ACFinder 060620版
 kabe WEB  (06/06/20 23:21)

引用なし
   kabe です。

060620版です。
http://acfinder.kabe.info/

#323,#326の修正を行いました。

〔332〕Re:ACFinder 060620版
 Hidemi Oya WEB  (06/06/21 16:06)

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

 毎度素早い修正をありがとうございます。
 前のバージョンからですが、定型処理タブで設定保存したときに、用途の設定に閉じシングルクォートがつかず、
yoto = '設定値…
となってしまいます。

 あと、屋号関係ですが、[#331] で書いた以外に、「三井ソイリーン」の「三井」(硫酸銅の方も後ろに(粉状)が付いてて適用が異なる他の硫酸銅と区別できるので取っちゃっても大丈夫そうです)、「東ソーシーゼットフロアブル」の「東ソー」、「三洋NCS」の「三洋」が適用がほぼ同じ農薬があるにもかかわらず取れていません。
 逆に、「三井シーゼットフラブル」や「ヤシマNCS」のように、他の同一通称の農薬とかなり適用が違うものは、別通称として認識された方が使いやすいかもという感じもします。1剤ものの農薬の屋号をあえて取るかどうかなども含めて、どこまで屋号を取ってしまうかは、なかなか悩ましいものがありますね(^_^;)。

>#323,#326の修正を行いました。
 #番号の両脇に [] を書いてもらうと、自動的に記事にリンクします。

〔333〕SQL ステートメント制限
 Hidemi Oya WEB  (06/06/22 11:45)

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

 テンポラリビューやテンポラリテーブルを使ったクエリを実行したいと思ったんですが、実行禁止になってました。複雑なクエリを一発で書くのは難しいですし、ビューで再利用したいクエリもあります。
 kihon, tekiyo テーブルを直接変更する可能性がある SQL 文のみを禁止し、あとは自由に使えるといいですね。下記のような感じでチェックできるのではないかと思います。index1, index2 は ACFinder が標準で使っているインデックス名を指定してください。

 あと、SQL のエラーメッセージも DecodeHex 関数で hex..... を ShiftJIS に戻してもらった方が見やすいです。おそらく、デバッグ用に Utf8ToAnsi のみにしてあったんじゃないかと思うのですが…。

RegExprModifierI := true;
RegExprModifierS := true;
if ExecRegExpr('(CREATE|DROP)\s+.*TABLE\s+.*(acis\.)?(kihon|tekiyo)', sql) then error;
if ExecRegExpr('(INSERT|REPLACE)\s+.*INTO\s+(acis\.)?(kihon|tekiyo)', sql) then error;
if ExecRegExpr('DELETE\s+FROM\s+(acis\.)?(kihon|tekiyo)', sql) then error;
if ExecRegExpr('UPDATE\s+.*(acis\.)?(kihon|tekiyo)', sql) then error;
if ExecRegExpr('CREATE\s+.*TRRIGER\s+.*ON\s+(acis\.)?(kihon|tekiyo)', sql) then error;
if ExecRegExpr('DROP\s+INDEX\s+.*(acis\.)?(index1|index2|....)', sql) then error;

〔334〕ACFinder 060622版
 kabe WEB  (06/06/22 22:22)

引用なし
   kabe です。

060622版です。
http://acfinder.kabe.info/

[#331][#332]の屋号の修正を行いました。
[#332]
>定型処理タブで設定保存したときに、用途の設定に閉じシングルクォートがつかず、
yoto = '設定値…
を修正しました。

[#333]の修正を行いました。

グリッド上でダブルクリックかエンターすると、該当行を別窓で表示します。

実験的にインデックスを増やしたので、データベースのファイルサイズが増えます。

〔335〕Re:SQL ステートメント制限
 kabe WEB  (06/06/22 22:46)

引用なし
   >Hidemi Oyaさん
kabe です。

> kihon, tekiyo テーブルを直接変更する可能性がある SQL 文のみを禁止し、あとは自由に使えるといいですね。下記のような感じでチェックできるのではないかと思います。
060622版に入れてみました。

ところで
[#328]
アグロス(?!リン|ター)
^キング(?!ダム|スタ)
をReplaceRegExprで使うとエラーになるのですが、どう書けばいいのでしょうか。

〔336〕Re:ACFinder 060622版
 Hidemi Oya WEB  (06/06/23 0:04)

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

>[#331][#332]の屋号の修正を行いました。
 三井シーゼットフロアブル、ヤシマNCSについては、別通称とするか同一通称とするか微妙ですね。薬剤タブで使用する時は、分かれてない方が使いやすいです。定型処理では別通称の方が都合が良さそうなんですが、大抵は対象作物を指定するでしょうから、同一通称でもあまり問題はないかもしれません。
 考えてみたら、キャベツの根こぶ病で通称NCSが検索されたとして、それにヤシマNCSが含まれているかどうかは名称を見るまで分からないわけで、だとすれば別通称としてもあまり意味はないかもしれませんね。

 定型処理や SQL で通称のみの表示にしても、たとえば検索結果の「農薬の種類」「名称」「通称」で右ボタンクリックすると「薬剤タブで検索」メニューが出て、薬剤候補にグリッドの値を設定して自動的に検索する機能があれば、簡単に個々の農薬の適用を確認することができますね。ついでに、「作物名」で右クリックすると「作物・病害虫タブで検索」メニューが出て、自動的に検索されるとか…。
 これができれば、同一通称で適用が異なる農薬も全て同じ通称としてしまっても何とかなりそうです。


>[#333]の修正を行いました。
 ありがとうございます。あとで試してみます。

〔337〕正規表現拡張構文
 Hidemi Oya WEB  (06/06/23 0:56)

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

>ところで
>[#328]
>アグロス(?!リン|ター)
>^キング(?!ダム|スタ)
>をReplaceRegExprで使うとエラーになるのですが、どう書けばいいのでしょうか。
RegExprModifierX := true;
で使えると思ったんですが、ヘルプを見ると全ての (?...) 拡張構文に対応してるわけじゃなさそうですね。試してみて、だめなら
http://www.regular-expressions.info/delphi.html
あたりを使うしかないですかねえ…(クラスと DLL を使うことになりますが)。

〔338〕Re:正規表現拡張構文
 Hidemi Oya WEB  (06/06/23 13:31)

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

>試してみて、だめなら
>http://www.regular-expressions.info/delphi.html
>あたりを使うしかないですかねえ…(クラスと DLL を使うことになりますが)。
 昨夜試してみたら、TRegExpr ではだめでした。で、こちらの PerlRegEx を試してみましたが、これがなかなか良さそうです。クラスを使いますが、ビジュアルコンポーネントになっているので、分かりやすいです(使い方が分かってしまえばビジュアルコンポーネントじゃない方が良いんですけど)。コンポーネントのコンパイル時に DLL の元となる .obj を取り込んでしまうので、実行ファイルに DLL を添付する必要もありません。
 本題の (?= ), (?! ), (?<= ), (?<! ), (?>= ), (?>! ) も問題なく使えそうです。TRegExpr では $1, $2, .., $n による置換だけで、\1, \2, .. , \n による置換には対応していませんでしたが、PrlRegEx はこちらにも対応しています。

 現在定型処理ルーチンをアップデート中ですが、こちらは PerlRegEx 対応にしますので、完成したらメールします。
 ちなみに、定型処理ルーチンのアップデート内容は下記の通り。
(1) 作物名、病害虫名、農薬の種類をメモコントロールで表示するとともに、サイズを可変に
(2) 設定可能項目に使用時期と使用方法を追加
(3) 設定項目を必須項目(未入力だとエラー)と推奨項目(未入力でもエラーにならない)の2種類に分ける

〔339〕Re:ACFinder 060622版
 kabe WEB  (06/06/23 19:46)

引用なし
   kabe です。

>[#333]の修正を行いました。
すいません。これ不完全です。
クエリーの結果が返ってくることしか想定していないので、create view などを実行すると検索結果がないというダイアログが出ます。
ただ実行自体はできます。

〔340〕Re:ACFinder 060622版
 Hidemi Oya WEB  (06/06/23 20:02)

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

>クエリーの結果が返ってくることしか想定していないので、create view などを実行すると検索結果がないというダイアログが出ます。
 本日確認して、ちょうど書こうと思ったところでした。SELECT 文以外では、結果がなくてもダイアログが出ないようにした方が良いですね。

〔341〕Re:SQL ステートメント制限
 s_kobayashi  (06/06/23 22:02)

引用なし
   >kabeさん、oyaさん

スレの趣旨とぜんぜん違うのですけれど。(^◇^;)

>^キング(?!ダム|スタ)

select meisho,ryakusho from kihon where meisho like "%キング%" group by meisho

上記sql文の検索結果によると、家庭園芸用に対応しようとする場合、屋号のキングは文頭に来るとは限りません。しかもホームランキング、クサキングなど本来の農薬名にキングを使うものが多数あるので単純に削除することもできません。対応策の検討が必要と思われます。

それと、ACFinderではtsushoのフィールドをtekiyoテーブルに置いていますが、これは検索の便宜を計るという意味でしょうか。tsushoはmeishoから生成されると考えるなら、kihonテーブル上にあるのが自然だと思うのですけれど、いかがでしょうか。

〔342〕「キング」対応パターン
 Hidemi Oya WEB  (06/06/24 0:05)

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

>上記sql文の検索結果によると、家庭園芸用に対応しようとする場合、屋号のキングは文頭に来るとは限りません。しかもホームランキング、クサキングなど本来の農薬名にキングを使うものが多数あるので単純に削除することもできません。対応策の検討が必要と思われます。
 MACS for ACIS では問題ありませんが、確かに中抜きしようとすると問題がでますね。方法としては次の2種類があると思いますが、どちらも一長一短ですね。

(1) 「キング」は別処理とする
方法:略称が「キング化学」の時だけ「キング」を抜く
欠点:「サンキングA」に対する例外処理が必要

(2) 中抜きしないパターンを列挙する
方法:パターンを「(?<!サン|ラン|クサ|リホ|トリ)キング(?!スタ|ダム)」にする
欠点:「○○キング」や「キング○○」が生まれるたびにパターン修正が必要

>それと、ACFinderではtsushoのフィールドをtekiyoテーブルに置いていますが、これは検索の便宜を計るという意味でしょうか。tsushoはmeishoから生成されると考えるなら、kihonテーブル上にあるのが自然だと思うのですけれど、いかがでしょうか。
 ACFinder の動作を見ていると、おそらく基本部で生成した通称を適用部に持ってきているのではなく、基本部は基本部、適用部は適用部でそれぞれのテーブルに存在する「農薬の名称」から個別に「通称」を生成しているのではないかと思います。現在の kihon テーブルを検索に使うことはあまりないので、tekiyo テーブルに通称があった方が使いやすいのも間違いありません。
 「元データが両方にあるなら、生成データも両方にあった方が自然だ」って論理も成り立ちます。せっかく RDBMS を使うのであれば無駄は省くべきと言う主旨であれば、通称だけでなく「用途」「農薬の種類」「農薬の名称」「略称」「混合数」も tekiyo テーブルから削除してしまった方が良いと思います。
LEFT JOIN kihon ON tekiyo.bango = kihon.bango
で簡単に結合できますから。

〔343〕テーブルの構成
 kabe WEB  (06/06/24 1:03)

引用なし
   >Hidemi Oyaさん
>s_kobayashi さん

kabe です。

> ACFinder の動作を見ていると、おそらく基本部で生成した通称を適用部に持ってきているのではなく、基本部は基本部、適用部は適用部でそれぞれのテーブルに存在する「農薬の名称」から個別に「通称」を生成しているのではないかと思います。
全くその通りです。

>せっかく RDBMS を使うのであれば無駄は省くべきと言う主旨であれば、通称だけでなく「用途」「農薬の種類」「農薬の名称」「略称」「混合数」も tekiyo テーブルから削除してしまった方が良いと思います。
どこまでテーブルを正規化するのか、悩ましいところですが、単純な使い勝手を考えると、現状の方法でもいいのかなと思います。なにせ、1回データベースを作ってしませばあとは検索だけの用途ですから。

ただ本来のデータベースということからすると、どういうテーブル構成にするのが理想的なのか、興味のあるところではあります。

基本部マスターテーブル
登録番号、農薬の種類、農薬の名称、農薬通称、会社名略称、混合数、用途、剤型

基本部有効成分テーブル
登録番号、有効成分、濃度

登録適用部 テーブル
登録番号、作物名、病害虫名、使用目的 〜 使用時期、使用方法、〜適用農薬

本剤の使用回数部分のテーブル
登録番号、作物名、本剤の使用回数
(ここまでやるか?)

登録適用部使用回数部分のテーブル
登録番号、作物名、有効成分、使用回数
(これがあると、防除暦を作成して、使用回数をチェックすることも可能か)

あと、適用部分はけっこう空値のあるフィールドが多いので、どこまで別テーブルにするべきか。

検索で使うにはビューを作ればいいので、元のテーブルは分割してもいいのですの ACFider でこれをやるとデータ更新の時間は今より確実に増えますね。

〔344〕Re:「キング」対応パターン
 s_kobayashi  (06/06/24 8:42)

引用なし
   >kabeさん、oyaさん

>>せっかく RDBMS を使うのであれば無駄は省くべきと言う主旨であれば、通称だけでなく「用途」「農薬の種類」「農薬の名称」「略称」「混合数」も tekiyo テーブルから削除してしまった方が良いと思います。
>どこまでテーブルを正規化するのか、悩ましいところですが、単純な使い勝手を考えると、現状の方法でもいいのかなと思います。なにせ、1回データベースを作ってしませばあとは検索だけの用途ですから。

 書き換えを行うDBの場合は正規化しないと整合性のチェックなどが面倒になりますが、読み出しだけの場合は、単に使い勝手とデータ肥大のトレードオフだけですよね。今回のデータの場合、元データの形式を崩すとexcelデータとの見比べが出来なくなるなど却って使い勝手が低下する側面もあるので、やみくもに正規化する必要はないと思います。

 私のいまのDBでは、kihon,tekiyoに加えて、tsushoというテーブルを試行しています。

mysql> describe tsusho;
+--------+---------+------+-----+---------+----------------+
| Field | Type  | Null | Key | Default | Extra     |
+--------+---------+------+-----+---------+----------------+
| num  | int(10) |   | PRI | NULL  | auto_increment |
| bango | int(11) | YES |   | NULL  |        |
| tsusho | blob  | YES |   | NULL  |        |
+--------+---------+------+-----+---------+----------------+

 numは単なるユニーク値です。bangoは他のテーブルと同じ農薬登録番号です。kihon.meisho から生成された屋号抜き農薬名が tsusho に格納されます。kihon.meisho は複数成分の剤については複数行になっていますが、tsusho は複数成分の剤でも1行だけにしています。

 実際にはもう一つ yago というフィールドを作って、除去された屋号の文字列を格納するようにすれば、置換が適正に動作しているかチェックがしやすいかなと思っています。

〔345〕Re:「キング」対応パターン
 Hidemi Oya WEB  (06/06/24 10:58)

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

 もうひとつ方法がありました。これが一番素直かな…。

(3) 「(家庭)?園芸用(用)?|産業」は削除したあと書き戻す

$t =~ s/フマキラー印/家庭園芸用/; # フマキラー印スミチオン乳剤、マラソン乳剤への対応
# フマキラー印対策の次に「(家庭)?園芸用(用)?|産業」の削除を実行する
$t =~ s/((家庭)?園芸(用)?|産業)//; # 「(家庭)園芸(用)」「産業」削除
$prefix = $1; 削除した接頭語を保存
$t =~ s/(.*?)$//; # 末尾括弧を削除
  :
$t =~ s/^[ \-]//; # 屋号と商品名の間の半角スペースを除去
$t = $prefix.$t; # 削除した接頭語を付け直す

〔346〕Re:テーブルの構成
 Hidemi Oya WEB  (06/06/24 12:04)

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

[#343] kabe さん

>どこまでテーブルを正規化するのか、悩ましいところですが、単純な使い勝手を考えると、現状の方法でもいいのかなと思います。
 私もそう思います。

>ただ本来のデータベースということからすると、どういうテーブル構成にするのが理想的なのか、興味のあるところではあります。
 ひとつの ID に対して複数の行が存在する場合は、テーブルを分けるってのが原則なんでしょうね。とすると、[#343] が素直なテーブル構成だといえますね。あとは、作物名、病害虫名はテーブルを別に持ち、適用表には ID のみを保存するってところでしょうか…。
 実際にここまでする必要はありませんが、作物名については、上位分類や詳細作物名まで一気に検索するには、作物コードで検索できた方が便利かもしれませんね。

>あと、適用部分はけっこう空値のあるフィールドが多いので、どこまで別テーブルにするべきか。
 VARCHAR ならデータ領域がそれほど無駄になるわけでもないので、これは1テーブルで良いかな…。

>ACFider でこれをやるとデータ更新の時間は今より確実に増えますね。
 今でも結構かかるので、こいつが一番ネックですね。ただ、本題の通称に関しては、tekiyo テーブルでひとつずつ作ると膨大な数を処理しなければならないので、s_kobayashi さんの提案通り kihon テーブルのみとした方が更新時間は短縮できそうですね。

[#344] s_kobayashi さん

>今回のデータの場合、元データの形式を崩すとexcelデータとの見比べが出来なくなるなど却って使い勝手が低下する側面もあるので、やみくもに正規化する必要はないと思います。
 おっしゃるとおりだと思います(ま、kabe さんも実際にやるつもりは毛頭なさそうですけど)。が、[#342] で書いたように kihon テーブルと重複している「用途」「農薬の種類」「農薬の名称」「略称」「混合数」を tekiyo テーブルから削除するくらいであれば、下記のようなビューで簡単に元の Excel の表に戻せます。
 といっても、実際にこれをやるかどうかは、
(1) EXCEL 入出力コンポーネントから、重複部分を削除した INSERT 文を生成するのに要する時間
(2) SQLite でフルデータを書き込むのと短縮データを書き込むのに要する時間の差
を調べて判断する必要があります。

CREATE VIEW tekiyo AS
SELECT
 a.bango AS bango,
 kihon.yoto AS yoto,
 kihon.shurui AS shurui,
 kihon.meisho AS meisho,
 kihon.tsusho AS tsusho,
 kihon.ryakusho AS ryakusho,
 a.sakumotsu AS sakumotsu,
 a.basho AS basho,
  :
 a.kaisu5 AS kaisu
FROM compact_tekiyo AS a
LEFT JOIN kihon ON a.bango = kihon.bango

〔347〕Re:テーブルの構成
 kabe WEB  (06/06/24 17:24)

引用なし
   >Hidemi Oyaさん
>s_kobayashi さん

kabe です。

> 実際にここまでする必要はありませんが、作物名については、上位分類や詳細作物名まで一気に検索するには、作物コードで検索できた方が便利かもしれませんね。
作物名だけのテーブルを農薬検査所の検索システムのHTMLソースから作って、利用できないかなと思ってますが、まだ手はつけていません。

> 今でも結構かかるので、こいつが一番ネックですね。ただ、本題の通称に関しては、tekiyo テーブルでひとつずつ作ると膨大な数を処理しなければならないので、s_kobayashi さんの提案通り kihon テーブルのみとした方が更新時間は短縮できそうですね。
Excelファイルの読み込みとデータベース更新部分で比較してみました。
屋号抜き取り処理を kihon テーブルだけにして、tekiyo テーブルには登録番号のみで基本テーブルにあるデータは含めない。
(インデックス作成前まで)
私のPCで大体こんな時間です。(acis.dbは新規作成)
現行バージョン 変換時間>0:01:27
acis.db ファイルサイズ 55MB
修正バージョン 変換時間>0:01:14
acis.db ファイルサイズ 28MB

なお、acis.dbが存在する場合には、最初に既存のテーブルを削除する操作をしていますが、これが加わると時間差が広がります。
現行バージョン 変換時間>0:01:54
修正バージョン 変換時間>0:01:22
この場合で30秒くらいは短縮できそうです。
やはり、10万レコード近い tekiyo テーブルで屋号抜き取り処理をやるのは無駄ですね。データベースのファイルサイズを考えても、登録番号で kihon テーブルから引けるフィールドは持たないことにした方がよさそうです。

あと現状の tekiyo テーブルに tsusho フィールドが必要な理由としては、作物、病害虫検索時の通称モードでは tsusho フィールドをベースに select distinct で重複する適用を表示しないようビューを作成して検索に使用していることが上げられます。
このビューには登録番号が存在しないので、bango をキーにして、農薬名を引いてくることができません。
現状の tekiyo と同じビューを基に、通称検索用のビューを作る方式にしたいと思います。

〔348〕Re:テーブルの構成
 Hidemi Oya WEB  (06/06/24 21:56)

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

>作物名だけのテーブルを農薬検査所の検索システムのHTMLソースから作って、利用できないかなと思ってますが、まだ手はつけていません。
 こちらも期待しています。

>Excelファイルの読み込みとデータベース更新部分で比較してみました。
 acis.db 新規作成で 13 秒差…。tekiyo テーブルから重複項目を抜くのは今までより処理が増えると思うんですが、それにも増して屋号カットルーチンを外した影響の方が大きいということですね。

>なお、acis.dbが存在する場合には、最初に既存のテーブルを削除する操作をしていますが、これが加わると時間差が広がります。
 DROP TABLE が加わると 32 秒差、25 %の短縮はでかいですね。それにしても、データサイズが大きいので、DROP TABLE が思いの外時間を食ってるんですねえ…。 現行バージョンで DROP TABLE の有り無しで 17 秒差、修正バージョンの DROP TABLE 有り無しで8秒差、ちょうどファイルサイズと正比例しますね。シングルファイルだからある程度はやむを得ないと思いますが、DROP TABLE にここまでかかるとは…。

 この結果を見ると、データ更新速度の向上という点では、屋号カットは kihon テーブルのみ、tekiyo テーブルから重複項目を削除するってのは、かなりおかげが大きいです。どうせなら、更新のたびにデータベース再作成ってのが良いかもしれません。今のところ、定型処理でもパーマネントビューは使う予定がないので、データベースの再作成でも OK です。
 問題は、テーブルを連結して使うことになる検索速度ですね。今までより若干遅くなりそうですが、ローカルディスクなら大丈夫でしょうか…。LAN 経由だと体感できる速度差があるかな?

>あと現状の tekiyo テーブルに tsusho フィールドが必要な理由としては、作物、病害虫検索時の通称モードでは tsusho フィールドをベースに select distinct で重複する適用を表示しないようビューを作成して検索に使用していることが上げられます。
 この話とは直接関係ありませんが…。SQLite ではあまり差を感じませんが、一般的に DISTINCT は時間がかかるので、表示行数が多くなる場合は GROUP BY を使った方が良いといわれています。

〔349〕Re:テーブルの構成
 kabe WEB  (06/06/24 22:29)

引用なし
   >Hidemi Oyaさん
kabe です。

> acis.db 新規作成で 13 秒差…。tekiyo テーブルから重複項目を抜くのは今までより処理が増えると思うんですが、それにも増して屋号カットルーチンを外した影響の方が大きいということですね。
いや、insert into するフィールド数は逆に少なくなるので、これも少しは貢献しているかもしれません。

>どうせなら、更新のたびにデータベース再作成ってのが良いかもしれません。
どうも、これが良さそうです。

> 問題は、テーブルを連結して使うことになる検索速度ですね。今までより若干遅くなりそうですが、ローカルディスクなら大丈夫でしょうか…。
体感的には、少し遅くなったような気がします。
検索部分で時間測定をしてみます。

>表示行数が多くなる場合は GROUP BY を使った方が良いといわれています。
これも試してみます。

〔350〕Re:テーブルの構成
 Hidemi Oya WEB  (06/06/25 3:04)

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

>いや、insert into するフィールド数は逆に少なくなるので、これも少しは貢献しているかもしれません。
 そうか、今までも Sheets[No].Strings[Row] で取り出したカンマテキストをそのまま INSERT 文の値として渡すんじゃなくて、ダブルクォートしたりするルーチンが入っていたので、フィールドを抜く処理を追加してもそれほど大きな影響はないんですね。それよりも、DROP TABLE と同様に INSERT するフィールド数が少ない方が書き込みが速くなる影響の方が大きいと…。

 ところで、現在は Excel ファイルを見えない TStringGrid か何かに一括して保存してから SQLite に書き込んでますよね? TStringGrid や TStringList は、データ数が多くなるとだんだん遅くなるので、下記のように1行読むごとに INSERT 文を発行する方式にすれば、もっと速くなりませんかね?

unit Unit1;

interface

uses
 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
 Dialogs, ComCtrls, StdCtrls, ExtCtrls, XBiff;

type
 TForm1 = class(TForm)
  XBiff1: TXBiff;
  Button1: TButton;
  ProgressBar1: TProgressBar;
  procedure Button1Click(Sender: TObject);
  procedure XBiff1Progress(Sender: TObject; Progress: Integer);
  procedure XBiff1ReadCell(Sender: TObject; SheetNo, Row, Col,
   rgbAttr: Integer; Data: String; var Cancel: Boolean);
  procedure XBiff1ReadSheetName(Sender: TObject; SheetName: String);
 private { Private 宣言 }
  FValidSheet: boolean;
  FRow: TStringList;
  procedure InsertRow;
 public { Public 宣言 }
 end;

var
 Form1: TForm1;

implementation

{$R *.dfm}

function HanToZen(s: string): string;
begin
 // 実際には変換ルーチンが入る
 Result := s;
end;

procedure TForm1.InsertRow;
var
 sql: string;
begin
 if FRow.Text = '' then Exit;
 sql := 'INSERT INTO tekiyo VALUES(' + FRow.DelimitedText + ')';
 FRow.Clear;
 // ここで SQLite に INSERT 文発行
end;

// Excel ファイル読み込み&SQLiteに保存
procedure TForm1.Button1Click(Sender: TObject);
begin
 FRow := TStringList.Create;
 try
  FRow.QuoteChar := '''';
  ProgressBar1.Position := 0;
  XBiff1.LoadFile('test.xls');
  InsertRow; // 最後の行を保存
 finally
  FRow.Free;
 end;
end;

procedure TForm1.XBiff1Progress(Sender: TObject; Progress: Integer);
begin
 ProgressBar1.Position := Progress;
end;

procedure TForm1.XBiff1ReadSheetName(Sender: TObject; SheetName: String);
begin
 FValidSheet := SheetName = '登録適用部';
end;

procedure TForm1.XBiff1ReadCell(Sender: TObject; SheetNo, Row, Col,
 rgbAttr: Integer; Data: String; var Cancel: Boolean);
begin
 if not FValidSheet then Exit;
 if Row = 0 then Exit;
 case Col of
  5..8, 13, 18: FRow.Strings[Col - 4] := AnsiToUtf8(AnsiQuotedStr(HanToZen(Data), '"'));
  9..12, 14..17: FRow.Strings[Col - 4] := AnsiToUtf8(AnsiQuotedStr(Data, '"'));
  20..24: FRow.Strings[Col - 5] := AnsiToUtf8(AnsiQuotedStr(Data, '"'));
  0: begin
   InsertRow; // 前の行を保存
   FRow.DelimitedText := Data + ',"","","","","","","","","","","","","","","","","","",""';
  end;
 end;
end;

end.

〔351〕Re:テーブルの構成
 kabe WEB  (06/06/25 14:24)

引用なし
   kabe です。

>現状の tekiyo と同じビューを基に、通称検索用のビューを作る方式にしたいと思います。
と、思ったのですが
LEFT JOIN kihon ON a.bango = kihon.bango
でビューを作るとレコード数が 153362件にもなってしまいます。
(実テーブルは95966レコード)
なんでだ〜と思ったのですが、kihon テーブルの登録番号は有効成分の数だけ同じ登録番号が存在するので、その分、レコード数が増えてしまいます。
本来のマスターテーブルとして登録番号をプライマリーキーにした、テーブルを作る必要がありますね。

〔352〕Re:テーブルの構成
 kabe WEB  (06/06/25 15:03)

引用なし
   >Hidemi Oyaさん
kabe です。

> ところで、現在は Excel ファイルを見えない TStringGrid か何かに一括して保存してから SQLite に書き込んでますよね?
Excel入出コンポのサンプルどおり、TStringListに全部読み込んだ後に、SQLite に書き込んでいます。
正確にはSQLite に書き込む前に、列数をそろえるため(使用回数1〜5が行ごとに異なるため)もう1回StringListのCount分ループを回しています。

>TStringGrid や TStringList は、データ数が多くなるとだんだん遅くなるので、下記のように1行読むごとに INSERT 文を発行する方式にすれば、もっと速くなりませんかね?
ちょっと、試してみましたが、どうもうまくいきません。
ReadCellイベントでうまくデータが拾えず挫折しています。(;_;
もちろん、[#350]のままのコードではないので、どこか不具合あるのだと思いますが、うまく動かすにはちょっと時間がかかりそうです。

ただ Excel の読み込み処理に一番時間がかかっているので、もう少し改善できないか取り組んでみます。
>FRow.DelimitedText := Data + ',"","","","","","","","","","","","","","","","","","",""';
0列目で最初に列数分、初期化すればいいんですね。
このあたり、参考になりそうです。

〔353〕Re:テーブルの構成
 Hidemi Oya WEB  (06/06/25 15:53)

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

>なんでだ〜と思ったのですが、kihon テーブルの登録番号は有効成分の数だけ同じ登録番号が存在するので、その分、レコード数が増えてしまいます。
 確かに、kihon テーブルをそのまま LEFT JOIN するとそうなりますね。SQLite は検索速度があまり落ちないので、すっかり見落としてました(^_^;)。
 だから、ひとつの ID に対して複数の行が存在する場合は、テーブルを分けるってのが原則なんでしょうから。

>本来のマスターテーブルとして登録番号をプライマリーキーにした、テーブルを作る必要がありますね。
 原則は原則として、検索速度に問題がなければ、下記のように有効成分を抜いて登録番号でグループ化するビューを作って、それを新 tekiyo ビューに LEFT JOIN するって手もありますね。

CREATE VIEW nkihon AS
SELECT
 bango, shurui, meisho, tsusho, ryakusho, kongo, yoto, zaikei
FROM kihon
GROUP BY bango;

CREATE VIEW tekiyo AS
SELECT
 a.bango AS bango,
 nkihon.yoto AS yoto,
 nkihon.zaikei AS zaikei,
 nkihon.shurui AS shurui,
 nkihon.meisho AS meisho,
 nkihon.tsusho AS tsusho,
 nkihon.ryakusho AS ryakusho,
 nkihon.kongo AS kongo,
 a.sakumotsu AS sakumotsu,
 a.basho AS basho,
  :
 a.kaisu5 AS kaisu
FROM compact_tekiyo AS a
LEFT JOIN nkihon ON a.bango = nkihon.bango;

〔354〕Excel 読み込み高速化
 Hidemi Oya WEB  (06/06/25 16:35)

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

>Excel入出コンポのサンプルどおり、TStringListに全部読み込んだ後に、SQLite に書き込んでいます。
 TStringList は、件数が増えると Add が目に見えて遅くなります。データの行データを全て読み込むのはちょっときついです。1行分の列データを保存する程度なら、それほど遅くありません。
 ってことで、1行分のデータを読み込むたびに INSERT 文を発行した方が高速化できる可能性が高いです。

>ReadCellイベントでうまくデータが拾えず挫折しています。(;_;
 私も細かくは検証していませんが、それなりに問題なさそうに思えましたが…。具体的に、どのようなデータが読めないのでしょう?
 サンプルだと、Col = 0 の時に行が変わったと判断して INSERT 文を発行していますが、Col = 0 にデータがない場合は、これだとダメですね。適用データは必ず登録番号があるのでこれでも大丈夫だと思いますが、Row 番号をメモリに保存しておいて、その値と現在の Row 番号が異なったら INSERT 文を発行する方が確実です。

>>FRow.DelimitedText := Data + ',"","","","","","","","","","","","","","","","","","",""';
>0列目で最初に列数分、初期化すればいいんですね。
 最初は OnReadCell イベントが発生するたびに単純に Add してたんですが、これだと列番号とデータが合いませんでした。それで、セルにデータがない時は OnReadCell イベントが発生しないことに気が付いた次第です(^_^;)。で、先にデータ領域を用意しておく方法として、これが最も単純な方法かなあと…。
 string の配列を用意しておいても良いのですが、あとでクォート付きカンマテキストに変換することを考えると、TStringList を使った方が楽ですから(速度的には不利になるかもしれませんが)。QuoteChar をシングルクォートにしておいて、CommaText ではなく Delimited テキストを使用することにより、空白データもそのまま初期化できますし…。なお、整数データの部分は、ダブルクォートなしにすれば OK です。

〔355〕Re:テーブルの構成
 kabe WEB  (06/06/25 16:48)

引用なし
   >Hidemi Oyaさん
kabe です。

> 問題は、テーブルを連結して使うことになる検索速度ですね。今までより若干遅くなりそうですが、ローカルディスクなら大丈夫でしょうか…。
テスト版を作成してみました。
http://acfinder.kabe.info/acfinder_060625_test.lzh
acis.db を1回削除してからデータ更新してください。
acis.db を消すと、ダイアログがうざいですが、ここは改良の余地ありです。(^^;
体感的にはそれほど、変わりないかなという気もします。
これで実用になりそうなら、この方式に変更します。
実テーブルは
kihon
m_kihon
m_tekiyo
の3つです。
m_kihon は登録番号をプライマリーキーにしたテーブルです。
従来の tekiyo は同一のフィールドでビューになっています。

〔356〕Re:テーブルの構成
 Hidemi Oya WEB  (06/06/25 18:28)

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

>体感的にはそれほど、変わりないかなという気もします。
 定型処理で結構複雑な表を作っても、ローカルディスクなら特に違和感はありません。[#353] で書いた方法と比べてみたら、明らかに分かるくらい実テーブルを使う方が速いです。

>これで実用になりそうなら、この方式に変更します。
 ってことで、成分がない kihon テーブルは、ビューを使うよりこの方式の方が良いですね。
 できれば、tekiyo ビューに「剤型」も追加してもらえると、定型処理で使いやすくなります(種類で like を使わなくてすみますから)。作物・病害虫タブでも、剤型による絞り込みができると便利なことが多いですし(特に水田主体の農家に対応する時など)。

 データベース作成も、私の環境(Barton 3200+ + 512MBx2 DualDDR400)で 00:01:17 でした。体感的にかなり速くなったと感じます。
 が、金曜日に事務所のメモリ 256MB のノートで前のバージョンを実行した時は、私が使っている 768MB のノートに比べてかなり遅かったような気がします。TStringList に全部読み込む方法だと、メモリサイズ及びアクセス速度の影響がもろに出るのだと思います。かなり速くなったとはいえ、[#352] の方法への転換が望まれます。
 それはそれとして、まだ試してませんが、データベースサイズが小さくなった分、もしかすると LAN 経由でも従来バージョンより速くなるかもしれませんね。

 [#353] 方式を試す時に気が付きましたが、今バージョンでは CREATE TEMP VIEW とかでダイアログボックス出なくなりましたね。ただ、SQL 分をセミコロンで区切って複数書いても、実行されるのは最初の文だけでしょうか? 前は、複数実行されたような気がしましたが…。

 定型処理のアップグレードに対応しやすくするため、現在 SQLite3.pas と SQLitTable3.pas を regexp 演算子に対応できるように修正しています。動作チェック環境が欲しいので、ACFinder のソースをメールしてもらえませんか?

〔357〕Re:テーブルの構成
 kabe WEB  (06/06/25 21:25)

引用なし
   >Hidemi Oyaさん

kabe です。

> できれば、tekiyo ビューに「剤型」も追加してもらえると、定型処理で使いやすくなります(種類で like を使わなくてすみますから)。
http://acfinder.kabe.info/acfinder_060625_test.lzh
剤型追加版に置き換えました。

ソースの方は、少しお待ちください。

〔358〕Re:テーブルの構成
 Hidemi Oya WEB  (06/06/25 22:41)

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

>http://acfinder.kabe.info/acfinder_060625_test.lzh
>剤型追加版に置き換えました。
 exe ファイルのタイムスタンプが変わってないので「あれ?」っと思ったんですが、
pramga table_info(tekiyo);
で確認したら、やっぱり前のテストバージョンと同じです。
 ちなみに、今回のデータ更新時間は、00:01:19 で acis.db を削除した場合とほとんど変わりませんでした。テストバージョンは、すでに更新のたびにデータベース再作成方式になってるんでしょうか?

 あとは、m_kihon テーブルに seibun1, seibun2, ..., seibun5 フィールドが追加されて、tekiyo ビューが seibun1, kaisu1, seibun2, kaisu2, ..., seibun5, kaisu5 てな具合にフィールドが並んでくれると、入手可能なデータから作成可能なテーブルとしてはもう完璧ですね。

>ソースの方は、少しお待ちください。
 了解です。今はまだ SQLite3.pas と SQLiteTable.pas に必要な関数を追加している段階なので(sqlite3.dll のソースと首っ引きです^^;)、それほど急ぐわけでもありません。

〔359〕Re:テーブルの構成
 Hidemi Oya WEB  (06/06/25 23:17)

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

 書き忘れてましたが、「剤型」も半角→全角変換するようにしてください。

〔360〕Re:テーブルの構成
 kabe WEB  (06/06/26 7:03)

引用なし
   >Hidemi Oyaさん
kabe です。

>で確認したら、やっぱり前のテストバージョンと同じです。
すいません。
FTPしたと思ったのですが、されてなかったようです。(^^;
更新しました。

> ちなみに、今回のデータ更新時間は、00:01:19 で acis.db を削除した場合とほとんど変わりませんでした。テストバージョンは、すでに更新のたびにデータベース再作成方式になってるんでしょうか?
いや、まだです。

〔361〕Re:テーブルの構成
 Hidemi Oya WEB  (06/06/26 20:53)

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

>更新しました。
 今度は OK です。剤型も全角に変換していただき、ありがとうございます。

>いや、まだです。
 事務所で使っている CeleronM 1.7?GHz DDR2-533 768MB で、db 新規作成 00:01:57、更新 00:02:07 でした。環境による差が大きいですね。INSERT は、メモリだけでなく CPU にもかなり依存しそうです。DROP TABLE に要する時間は、CPU と HDD かな?

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