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

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
82 / 114 ﾂﾘｰ <前へ | 次へ>
〔185〕ACFinder LocalDB版 kabe (06/05/31 22:51)
〔254〕ACFinder 060610版 kabe (06/06/10 21:38)
〔255〕Re:ACFinder 060610版 Hidemi Oya (06/06/10 23:05)
〔260〕Re:ACFinder 060610版 Hidemi Oya (06/06/11 1:39)
〔266〕屋号 Hidemi Oya (06/06/11 17:30)
〔269〕Re:屋号 Hidemi Oya (06/06/11 20:40)
〔256〕複数作物の登録状況一覧 SQL 例（通称対応） Hidemi Oya (06/06/10 23:09)
〔261〕Re:複数作物の登録状況一覧 SQL 例（通称対応... Hidemi Oya (06/06/11 8:46)
〔264〕Re:複数作物の登録状況一覧 SQL 例（通称対応... Hidemi Oya (06/06/11 10:56)
〔258〕対象病害虫一覧の SQL 例（通称対応） Hidemi Oya (06/06/11 0:32)
〔259〕Re:対象病害虫一覧の SQL 例（通称対応） Hidemi Oya (06/06/11 1:04)
〔262〕Re:ACFinder 060610版 Hidemi Oya (06/06/11 10:28)
〔263〕作物名の数字が全角に(;_;) Hidemi Oya (06/06/11 10:52)
〔265〕Re:ACFinder 060610版 s_kobayashi (06/06/11 12:09)
〔267〕Re:ACFinder 060610版 Hidemi Oya (06/06/11 17:51)
〔268〕Re:ACFinder 060610版 s_kobayashi (06/06/11 19:50)
〔272〕Re:ACFinder 060610版 kabe (06/06/11 21:19)
〔274〕Re:ACFinder 060610版 Hidemi Oya (06/06/11 23:28)
〔275〕Re:ACFinder 060610版 s_kobayashi (06/06/12 0:18)
〔276〕Re:ACFinder 060610版 Hidemi Oya (06/06/12 13:34)
〔282〕Re:ACFinder 060610版 s_kobayashi (06/06/15 0:28)
〔283〕Re:ACFinder 060610版 Hidemi Oya (06/06/15 1:30)
〔284〕Re:ACFinder 060610版 s_kobayashi (06/06/15 23:16)
〔293〕Re:ACFinder 060610版 kabe (06/06/17 21:54)
〔294〕定型処理サンプル Hidemi Oya (06/06/18 2:12)
〔297〕Re:定型処理サンプル Hidemi Oya (06/06/18 14:13)
〔254〕ACFinder 060610版
 kabe WEB  (06/06/10 21:38)
引用なし
   kabe です。

暫定修正版？です。
http://acfinder.kabe.info/

データベース作成の時間をかなり短縮しました。
Excelファイルからダイレクトにデータベースファイルに変換します。
変換作業にはExcelは不用です。
Excelがインストールされていない PC でも OKです。

検索機能については、農薬通称（屋号抜き）で表示するモードを追加してみました。
作物名は前よりは融通がきくようにしていますが、検証が不十分です。
ほとんど動作確認できていませんので、バグ出しにご協力ください。

テーブル kihon
seibun,nodo,zaikei
テーブル tekiyo
bango,yoto,shurui,meisho,tsusho,ryakusho,sakumotsu,basho,byochu,mokutek,
baisu,ekiryo,jiki,kaisu,hoho,jikan,ondo,dojo,chitai,noyaku,kongo,
kaisu1,kaisu2,kaisu3,kaisu4,kaisu5'

ですが、作物、病害虫検索については独自にビューを作成して検索しています。
〔255〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/10 23:05)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>暫定修正版？です。
　早速のアップデートお疲れ様です。

>データベース作成の時間をかなり短縮しました。
　一番時間がかかっていた CSV の正規化部分がなくなり、かなり速くなりましたね。前バージョンではちょっとデータ更新をためらう速度でしたが、今回は許容範囲かなという感じです。
　中間ファイルができなくなったのも HDD に優しくて良いです。

>検索機能については、農薬通称（屋号抜き）で表示するモードを追加してみました。
　これはなかなかいいですね。やはり、我々の用途ではこうでなくっちゃ！
　ただ、ツールバーだと、ボタンの表示状態が変わるとはいえ、ちょっと分かりづらいかも…。それと、検索表示が高速なので、ツールバーのボタンをクリックしたら表示も即座に切り替わる方が良いかもしれません。
　なお、通称対応版複数作物登録一覧を試している時に、以下の点について気が付きました。
イヅツＤＤＶＰ５０％乳剤の「イヅツ」が取れていない
シンジェンタ・トレボン乳剤の「・」が取れていない

>作物名は前よりは融通がきくようにしていますが、検証が不十分です。
　いいですねえ〜。ちょっと試しただけですが、「ｷｬﾍﾞﾂ」は「キャベツ」や「きゃべつ」で、「はくさい」は「ハクサイ」や「ﾊｸｻｲ」でも検索できました。文字列を確定してからのエンターキーの押下で検索実行されるのも good です。
　これが SQL でも使えると、すっごくありがたいんですけどね。=, <> や like などの比較演算子の右側にある文字列リテラルをだけを同じように変換するってできないんでしょうか？

　SQL にスクロールバーが付いたのと、条件消去で SQL も消去されるようになったのはありがたいです。

　通称対応版複数作物登録一覧を試している際に、もうひとつ気が付いた点があります。今バージョンでは、
max(case when sakumotsu like "だいこん%" then jiki||kaisu else "" end) だいこん
のようにフィールドエリアスに日本語を使ってもエラーにならなくなりましたが、AS を付けてもシングルクォートやダブルクォートで括ってみても、ヘッダにフィールド名が表示されません。これで、ヘッダに日本語が表示されるようになれば完璧です。
〔256〕複数作物の登録状況一覧 SQL 例（通称対応）
 Hidemi Oya WEB  (06/06/10 23:09)
引用なし
   　ACFinder 060610 版の新機能である「農薬通称」による複数作物の登録状況一覧の SQL 例です。

　[#218] の例では、農薬の種類を「水和剤」と「乳剤」に限定していたので、「水溶剤」が表示されませんでした。今回は、使用方法が「散布」で、農薬の種類が「粉剤」「粒剤」以外という条件に変更しています。このクエリの用途からいうと、「粉剤」は表示した方が良いかもしれませんが…。

select shurui, tsusho,
max(case when sakumotsu like "だいこん%" then jiki||kaisu else "" end) as daikon,
max(case when sakumotsu like "はくさい%" then jiki||kaisu else "" end) as hakusai,
max(case when sakumotsu like "ｷｬﾍﾞﾂ%" then jiki||kaisu else "" end) as cabbege,
max(case when sakumotsu like "ﾌﾞﾛｯｺﾘｰ%" then jiki||kaisu else "" end) as broccoli
from tekiyo where
yoto = "殺虫剤" and hoho = "散布" and shurui not like "%粉剤" and shurui not like "%粒剤" and
(sakumotsu like "だいこん%" or sakumotsu like "はくさい%" or sakumotsu like "ｷｬﾍﾞﾂ%" or sakumotsu like "ﾌﾞﾛｯｺﾘｰ%")
group by tsusho order by shurui
〔258〕対象病害虫一覧の SQL 例（通称対応）
 Hidemi Oya WEB  (06/06/11 0:32)
引用なし
   　ACFinder 060610 版の新機能である「農薬通称」による、対象病害虫一覧の SQL 例です。

　今回は希釈倍数・使用量も表示するようにしてみました。対象病害虫によって希釈倍数が異なる場合は薄い方を表示するようにしてあります。たとえば、「1000倍」と「1000〜2000倍」があれば「1000〜2000倍」、「1000〜2000倍」と「2000倍」があれば「2000倍」が表示されます。
　ただし、MAX 関数は左側から順に大小判定をするようで、「500倍」と「1000倍」がある場合は「500倍」が表示されてしまいます。今のところ、これを解決する方法は不明です(^_^;)。

select shurui, tsusho, max(baisu) as baisu, jiki, kaisu,
max(case byochu when "べと病" then "●" else "" end) as beto,
max(case byochu when "灰色かび病" then "●" else "" end) as haikabi,
max(case byochu when "うどんこ病" then "●" else "" end) as udonko,
max(case byochu when "斑点細菌病" then "●" else "" end) as hanten,
max(case byochu when "褐斑病" then "●" else "" end) as kappan,
max(case byochu when "菌核病" then "●" else "" end) as kinkaku
from tekiyo where sakumotsu like "きゅうり%" and hoho = "散布" and
(byochu = "べと病" or byochu = "灰色かび病" or byochu = "うどんこ病" or byochu = "斑点細菌病" or byochu = "褐斑病" or byochu = "菌核病")
group by tsusho order by shurui
〔259〕Re:対象病害虫一覧の SQL 例（通称対応）
 Hidemi Oya WEB  (06/06/11 1:04)
引用なし
   　農薬通称で一括する場合は農薬数が少ないので、当面 MAX 関数を使わずに希釈倍数でグルーピングして、希釈倍数が異なるモノを全て列挙するようにした方が間違いがないですね。
　ついでに、「きゅうり」ならなんでもではなく、「きゅうり」と「きゅうり（施設栽培）」だけにしてみました。

select shurui, tsusho, baisu, jiki, kaisu,
max(case byochu when "べと病" then "●" else "" end) as beto,
max(case byochu when "灰色かび病" then "●" else "" end) as haikabi,
max(case byochu when "うどんこ病" then "●" else "" end) as udonko,
max(case byochu when "斑点細菌病" then "●" else "" end) as hanten,
max(case byochu when "褐斑病" then "●" else "" end) as kappan,
max(case byochu when "菌核病" then "●" else "" end) as kinkaku
from tekiyo where (sakumotsu = "きゅうり" or sakumotsu = "きゅうり（施設栽培）") and hoho = "散布" and shurui not like "%粉剤" and shurui not like "%粒剤" and
(byochu = "べと病" or byochu = "灰色かび病" or byochu = "うどんこ病" or byochu = "斑点細菌病" or byochu = "褐斑病" or byochu = "菌核病")
group by baisu, tsusho order by shurui
〔260〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 1:39)
引用なし
   要望をもう一つ追加です。

　データベース更新がかなり速くなったとはいえ、待ち時間いらずというわけにはいきません。SQLite はデータベースファイルを共有しても問題なく使用できるように作られているようなので、事務所で使うような場合は、基本設定にデータベースパスを追加して、データベースファイルを共有できると良いですね。これだと、誰かが更新すれば、他の人は更新しなくてすみます。
　システム全体をサーバにおいて共有すれば、上記のような設定は不要になりますが、確か農薬ナビ版や農薬検査所版ではこういう使い方はできませんでした。試してないけど、今バージョンは大丈夫なのかな？
〔261〕Re:複数作物の登録状況一覧 SQL 例（通称対...
 Hidemi Oya WEB  (06/06/11 8:46)
引用なし
   　農薬通称だと検索農薬数が激減するので、用途を表示して、「殺虫剤」「殺菌剤」「殺虫殺菌剤」を一括して検索するという手もありますね（稲では農薬数が多すぎて使えませんが）。

select yoto, shurui, tsusho,
max(case when sakumotsu like "だいこん%" then jiki||"、 "||kaisu else "" end) as daikon,
max(case when sakumotsu like "はくさい%" then jiki||"、 "||kaisu else "" end) as hakusai,
max(case when sakumotsu like "ｷｬﾍﾞﾂ%" then jiki||"、 "||kaisu else "" end) as cabbege,
max(case when sakumotsu like "ﾌﾞﾛｯｺﾘｰ%" then jiki||"、 "||kaisu else "" end) as broccoli
from tekiyo where
(yoto like "殺虫%" or yoto like "%殺菌剤") and hoho = "散布" and shurui not like "%粉剤" and shurui not like "%粒剤" and
(sakumotsu like "だいこん%" or sakumotsu like "はくさい%" or sakumotsu like "ｷｬﾍﾞﾂ%" or sakumotsu like "ﾌﾞﾛｯｺﾘｰ%")
group by tsusho order by yoto, shurui, tsusho
〔262〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 10:28)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　作物名のワイルドカードですが、「不知火」や「温州」のように全部漢字だと、'%不知火%' のようにキーワードの両サイドに付きますが、「温州みかん」や「ぽんかん」だと 'ぽんかん%' と末尾にのみ付きます。このため、植調剤（ジベレリン、MCPB）のように作物名が「かんきつ（温州みかん、伊予柑、不知火、サガマンダリン、ぽんかん）」のような表記の農薬は、「不知火」は全部検索できても「ぽんかん」は検索落ちが発生します。
　おそらく、「ねぎ」と「たまねぎ」や、「トマト」と「ミニトマト」を区別するために、ひらがな／カタカナが混ざっているものはワイルドカードを末尾のみに付ける仕様にしてあるのだと推測します。上記のようなケースでなくても、'%なす%' で検索すると「野菜類（なすを除く）」まで拾ってきてしまうという弊害も出ますしね。
　とはいえ、最初のジベレリンのようなケースを検索できないのも不便なので、ワイルドカードの自動付与は一律末尾のみにし、頭に付けたい場合はユーザが自分で付けるってのでどうでしょう？

　正規表現が使えれば、上記の何れのケースにでも対応できる検索条件を自動的に設定することが可能です。暇が出来たら、Delphi での実装を検討してみます。
〔263〕作物名の数字が全角に(;_;)
 Hidemi Oya WEB  (06/06/11 10:52)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>作物名は前よりは融通がきくようにしていますが、検証が不十分です。
　「ぶどう(巨峰系4倍体品種)」が「ぶどう(巨峰系４倍体品種)」に変換されてしまい、検索できません。「ぶどう(2倍体欧州系品種)」等も同様です。
　とりあえず、現行のデータ保存方法では、作物名の数字は全角変換しないようにする必要がありますね。
〔264〕Re:複数作物の登録状況一覧 SQL 例（通称対...
 Hidemi Oya WEB  (06/06/11 10:56)
引用なし
   　うちの母ちゃんに依頼された実例です。なす、ピーマン、かぼちゃについては、（）無しと（露地栽培）のみということで、検索条件で全て列挙する方式です。

select yoto, shurui, tsusho,
max(case when sakumotsu like "なす%" then jiki||"、 "||kaisu else "" end) as nasu,
max(case when sakumotsu like "ﾋﾟｰﾏﾝ%" then jiki||"、 "||kaisu else "" end) as pman,
max(case when sakumotsu like "かぼちゃ%" then jiki||"、 "||kaisu else "" end) as kabocha,
max(case when sakumotsu = "にがうり" then jiki||"、 "||kaisu else "" end) as goya,
max(case when sakumotsu = "ｵｸﾗ" then jiki||"、 "||kaisu else "" end) as okura
from tekiyo where
(yoto like "殺虫%" or yoto like "%殺菌剤") and hoho = "散布" and shurui not like "%粉剤" and shurui not like "%粒剤" and
sakumotsu in ("なす", "なす（露地栽培）", "ﾋﾟｰﾏﾝ", "ﾋﾟｰﾏﾝ（露地栽培）", "かぼちゃ", "かぼちゃ（露地栽培）", "にがうり", "ｵｸﾗ")
group by tsusho order by yoto, shurui, tsusho
〔265〕Re:ACFinder 060610版
 s_kobayashi  (06/06/11 12:09)
引用なし
   ＞kabeさん

いくつか気づいた点を報告します。

（１）sqlを打つ人のために、テーブル名、フィールド名をどこかで分かるようにして頂ければ助かります。

（２）以下の通称に不具合がありました。
×ﾔｼﾏ産業ﾛﾌﾞﾗｰﾙﾌﾛｱﾌﾞﾙ→産業ﾛﾌﾞﾗｰﾙﾌﾛｱﾌﾞﾙ
×三共の草枯らし→の草枯らし
×ﾁﾊﾞｶﾞｲｷﾞｰ･農将軍ﾌﾛｱﾌﾞﾙ→･農将軍ﾌﾛｱﾌﾞﾙ
×ｼﾝｼﾞｪﾝﾀ･ﾄﾚﾎﾞﾝ乳剤→･ﾄﾚﾎﾞﾝ乳剤
×ｺｰﾌﾟｹﾐｶﾙ粒状石灰窒素40→ｺｰﾌﾟｹﾐｶﾙ粒状石灰窒素40
×ｴｽ･ｶ･ﾍﾞｰ粒状石灰窒素→ｴｽ･ｶ･ﾍﾞｰ粒状石灰窒素
×ｴｽ･ｶ･ﾍﾞｰ石灰窒素50防散→ｴｽ･ｶ･ﾍﾞｰ石灰窒素50
「家庭園芸用」という言葉の扱いをどうするか。削除？

（３）通称と名称が違う（置換済み）ことを示すフラグのフィールドがあれば便利だと思いました。（サブクエリで作り出すこともできますけれど。）

（４）エクセル出力時などに、何日時点のデータから作成したかが分かるような工夫があればよいと思いました。

（５）sqlからdeleteやdrop tableができました。そのような使い方をすることはほとんどないので、検索のみに権限を制限する方が良いと思います。
〔266〕屋号
 Hidemi Oya WEB  (06/06/11 17:30)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

　[#255][#265] 以外では、「サイアナミッド」「カヤク(・)」「イヅツヤ」(これは tm.pm も^^;)が全く削除されません。サイアナミッドは以前 kabe さんに教えてもらったものなので、抜けじゃなくて削除文字列が間違ってるのかも？
　あと、硫酸銅で「マルア」「エルピー」「小名浜」、石灰硫黄合剤で「カダン」が削除されません。

　「シンジェンタ・」と「チバガイギー・」のような「・」の取り扱いについては、tm.pm では屋号に続いて存在する「・」は一括削除するようにしています。このほか、屋号接尾語として「−」「印」「の」「　」については、「・」と同様の処理です。
　Delphi だと、
(1) 屋号前後の「」〔〕［］を削除
(2) 屋号直後の接尾語を削除
って感じで処理できるのでは？

　また、多数の屋号が存在する「硫酸銅」「(粉末)生石灰」「石灰硫黄合剤」「石灰窒素」「エムダイファー」については、登録屋号を削除するのではなく、通称の前にある文字を全て削除するようにしています。
〔267〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 17:51)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>（１）sqlを打つ人のために、テーブル名、フィールド名をどこかで分かるようにして頂ければ助かります。
　Access のように GUI で SQL を作れるようになるか、Microsoft や Borland の IDE のようにエディタに自動補完機能が付くと楽なんですが、難しいでしょうねえ(^_^;)。

>「家庭園芸用」という言葉の扱いをどうするか。削除？
　このほか、「園芸用」「園芸」「産業」がありますが、一般的な同じ通称の農薬とは適用が異なることがあるので、削除せずに別通称とした方が良いと思います。ACFinder では、通称で表示された適用がどの名称の農薬のモノであるかを確認できませんから。
　macs for acis では削除して同一通称としていますが、これは携帯電話の小さな画面ではこれらを別表示にすると使いづらくなることと、表示する適用があくまでも個々の名称の農薬のモノであることが明確だからです。

>（３）通称と名称が違う（置換済み）ことを示すフラグのフィールドがあれば便利だと思いました。（サブクエリで作り出すこともできますけれど。）
　各レコードにですか？ どのような用途を想定しているのでしょう？
〔268〕Re:ACFinder 060610版
 s_kobayashi  (06/06/11 19:50)
引用なし
   ＞Hidemi Oyaさん

>　Access のように GUI で SQL を作れるようになるか、Microsoft や Borland の IDE のようにエディタに自動補完機能が付くと楽なんですが、難しいでしょうねえ(^_^;)。

　そこまで便利にするのは難しいかもしれませんが、テーブル名、フィールド名、SQLの方言などがぱっと参照できればかなり生産性が高まると思います。SQLに堪能な人でもこれらの情報が示されていないとほとんど何も出来ません。いずれも設計時点で決まっていますし、一度インストールしたACFinderの内部構造は使っている間に変更されることもありませんから、単純な定型文表示でもいいと思います。

>>「家庭園芸用」という言葉の扱いをどうするか。削除？
>　このほか、「園芸用」「園芸」「産業」がありますが、一般的な同じ通称の農薬とは適用が異なることがあるので、削除せずに別通称とした方が良いと思います。ACFinder では、通称で表示された適用がどの名称の農薬のモノであるかを確認できませんから。
>　macs for acis では削除して同一通称としていますが、これは携帯電話の小さな画面ではこれらを別表示にすると使いづらくなることと、表示する適用があくまでも個々の名称の農薬のモノであることが明確だからです。

　了解しました。

>>（３）通称と名称が違う（置換済み）ことを示すフラグのフィールドがあれば便利だと思いました。（サブクエリで作り出すこともできますけれど。）
>　各レコードにですか？ どのような用途を想定しているのでしょう？

　いろいろ考えてみましたが、各レコードに置くほどのことはないですね。where節やサブクエリで十分対応できそうです。
〔269〕Re:屋号
 Hidemi Oya WEB  (06/06/11 20:40)
引用なし
   >kabe さん、こん＊＊は。Hidemi Oya です。

>　Delphi だと、
>(1) 屋号前後の「」〔〕［］を削除
>(2) 屋号直後の接尾語を削除
>って感じで処理できるのでは？
　'」〕］'の後ろに '・−印の　' が付くことはないでしょうから、
(1) 屋号直前の '「〔［' を削除
(2) 屋号直後の '」〕］・−印の　' を削除
の方がプログラムは楽かもしれませんね。
〔272〕Re:ACFinder 060610版
 kabe WEB  (06/06/11 21:19)
引用なし
   ＞Hidemi Oyaさん
＞s_kobayashi さん

kabe です。

>>（１）sqlを打つ人のために、テーブル名、フィールド名をどこかで分かるようにして頂ければ助かります。
>　Access のように GUI で SQL を作れるようになるか、Microsoft や Borland の IDE のようにエディタに自動補完機能が付くと楽なんですが、難しいでしょうねえ
ここまでは無理としても、将来的に簡易なSQLエディタ的なものは付けたいと思います。現状では入力ボックスが小さすぎるので、別窓で入力するか、あるいはグリッドごと別タブにしようかなと思います。

これも含めて現状では検索結果を表示するグリッドが１個しかないので、タブ切り替えブラウザみたいに複数の検索結果を表示できるようにしたいと考えています。
（今のところ構想だけですが）
〔274〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 23:28)
引用なし
   kabe さん、s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>ここまでは無理としても、将来的に簡易なSQLエディタ的なものは付けたいと思います。
　ちょっと考えていたことがあります。設定パネルに、テーブル選択コンボボックス(選択のみ)と追加ボタン、フィールド選択コンボボックス(選択のみ)と追加／条件ボタンを配置しておきます。で、テーブルを選択して追加ボタンをクリックすると、テキストボックスに
select　from tekiyo where
のように基本フレームが入ります。select　from の間にキャレットを置き、フィールドを選択して追加ボタンをクリックすると、
select meisho from tekiyo where
のようフィールド名が追加されます。where の後ろにキャレットを置き、フィールドを選択して条件ボタンをクリックすると、比較演算子選択コンボボックスとフィールド内容リストボックスで構成されたダイアログボックスが表示され、比較演算子と条件として使用する値を選択(比較演算子が IN の場合は複数選択)すると
select meisho from tekiyo where sakumotsu = '移植水稲'
のように検索条件が入ります。
　言葉ではイメージがつかみづらいかもしれませんが、これくらいなら比較的簡単に実装できると思いますし、SQL の作成は飛躍的に楽になると思います。

>現状では入力ボックスが小さすぎるので、別窓で入力するか、あるいはグリッドごと別タブにしようかなと思います。
　たしかに、現在はちょっと狭くて不便です。別窓と別タブなら、別タブに１票。SQL タブと結果タブがあるというイメージです。

>これも含めて現状では検索結果を表示するグリッドが１個しかないので、タブ切り替えブラウザみたいに複数の検索結果を表示できるようにしたいと考えています。
　どの検索条件とどの検索結果がリンクしているかを分かるように作るのは、なかなか難しいかもしれません。
　現在は、「作物・病害虫」「薬剤」「SQL」のページコントロールがツールバーに入っていて、結果表示用のストリンググリッドとリンクしていません。このページコントロールをツールバーから出してクライアント領域全体に置き、それぞれのタブの中に設定パネルとストリンググリッドを持つようにするってのはどうでしょう？(ログペインも共用型じゃなくてタブごとに独立してる方が良いかな？)
　これなら、それほど大きな変更なしに、少なくとも３項目の結果を独立して見ることができます。
〔275〕Re:ACFinder 060610版
 s_kobayashi  (06/06/12 0:18)
引用なし
   ＞Hidemi Oyaさん、abeさん

>select meisho from tekiyo where sakumotsu = '移植水稲'
>のように検索条件が入ります。
>　言葉ではイメージがつかみづらいかもしれませんが、これくらいなら比較的簡単に実装できると思いますし、SQL の作成は飛躍的に楽になると思います。

　ボタン操作でコマンドを積み上げていくようなイメージでしょうか。私のイメージとしては、ウイザードで「テーブル選択」「フィールド選択」「絞り込み条件」「ソート条件」くらいの４段階の指示でとりあえず動くSQLを吐き出してくれればもう十分かなと思います。

　付け加えていえば、適正な検索結果を出力できたSQL文を丸ごと覚えてくれる特殊ボタンがいくつかあるとうれしいです。私が作っている農薬検索CGIは個別ユーザー向けのカスタマイズが非常に難しいのですが、ACFinderのようなローカル完結型なら、SQL＋マクロ動作みたいな自動化が成り立つと思います。

　たとえば、ボタン１から「デラウエア登録農薬SQL」を呼び出して、エクセル印刷ボタンを押せばデラウエアに登録のある農薬（対象作物が落葉果樹、ぶどう、少粒種ぶどう、ぶどう（デラウエア）…のもの、但し県使用自粛農薬を除外）を検索し、結果をエクセルファイルに書き出し、印刷もしてくれるというような機能です。

　ま、このあたりは単なるアイデアですので、あんまり気にしないでください。(^^ゞ
〔276〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/12 13:34)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>　ボタン操作でコマンドを積み上げていくようなイメージでしょうか。
　というよりは、フィールド選択や条件設定の際に、いちいち覚えていなくてもソフトウェア側でアシストしてくれるというイメージです。

>私のイメージとしては、ウイザードで「テーブル選択」「フィールド選択」「絞り込み条件」「ソート条件」くらいの４段階の指示でとりあえず動くSQLを吐き出してくれればもう十分かなと思います。
　SQL を使いたくなるのは、基本的に非定型処理だと思います。他の項目はウィザードで処理してくれても、非定型処理の絞り込み条件をウィザードで設定できるようにウィザードを設計するのは至難の技でしょう。さらに、ウィザードで SQL の骨格を作ってくれたとしても、それを改良する際に上記のようなアシスト機能がないと難しいです。
　また、定型処理用 SQL を使うような場合も、誰かが作った骨格を自分の用途に合わせて修正するのが一般的な使い方ではないでしょうか？ だとすれば、SQL に詳しくなくてもサンプルをいかに楽に修正できるかをベースに付加機能を考えた方が多くの方が幸せになれると思います。
　が、皆が幸せになれるシステムを開発するためにはプログラマは地獄を見なければならないので、妥協点が提案したような方式だということです。

　s_kobayashi さんと私の意図する機能が大きく違うのは、前提条件が異なっているからだと思います。私は、基本的に SQL はなるべく使わなくてすむように、定型処理に関しては「作物・病害虫」や「農薬」タブのように、基本事項の設定だけすれば 事足りる状態にしておくのが望ましいと思います。たとえば、対象病害虫一覧や複数作物登録状況などがよく使われるとするなら、それは定型処理として専用タブ内に条件設定機能を作っておくということです。
　ただし、この機能で [#264] のように「なす」と「なす（露地栽培）」をひとまとめにするような設定まで作り込むのはかなり面倒です。タブ内で使えるのは、「なす」と「なす（露地栽培）」は別作物として作表する機能までという感じで良いと思います。で、「なす」と「なす（露地栽培）」をひとまとめにしたければ、このタブで作成されたクエリを SQL タブにコピーして手動修正するというような使い方ができれば楽だなというところです。
　現在は各タブが自動生成するクエリをログペインからコピーするしかないですが、できればボタン一発で SQL テキストボックスにクエリを貼り付けられると良いなあとは思います。

>　たとえば、ボタン１から「デラウエア登録農薬SQL」を呼び出して、エクセル印刷ボタンを押せばデラウエアに登録のある農薬（対象作物が落葉果樹、ぶどう、少粒種ぶどう、ぶどう（デラウエア）…のもの、但し県使用自粛農薬を除外）を検索し、結果をエクセルファイルに書き出し、印刷もしてくれるというような機能です。
　なるほど、よく使うクエリを複数のボタンに保存しておくということですね。その程度なら実装は難しくないと思います。が、現在の読み込みボタンで選択するのでも大差なく、ファイル名で選べる分選択も分かりやすいような気もします。
　それと、Excel で印刷までは難しいでしょうね。印刷用のフォントサイズやセル幅の設定については手動でやるしかないと思います。このツリーの中でも Excel 入れてないという人が２人いますし、用紙幅内で印刷するくらいで良いなら、反って HTML の方が向いているかな…。
〔282〕Re:ACFinder 060610版
 s_kobayashi  (06/06/15 0:28)
引用なし
   ＞Hidemi Oyaさん

>　s_kobayashi さんと私の意図する機能が大きく違うのは、前提条件が異なっているからだと思います。私は、基本的に SQL はなるべく使わなくてすむように、定型処理に関しては「作物・病害虫」や「農薬」タブのように、基本事項の設定だけすれば 事足りる状態にしておくのが望ましいと思います。たとえば、対象病害虫一覧や複数作物登録状況などがよく使われるとするなら、それは定型処理として専用タブ内に条件設定機能を作っておくということです。

　おっしゃるとおり、前提条件は違うように感じます。私にとってSQL直打ちは、利用者からの緊急要望にバージョンアップで対応できない場合、開発者（あるいは上級者）がSQLを提示して暫定的に解決するというイメージです。そのSQL文を継続的に使いたい場合はボタンに覚えさせれば便利という程度で、あまりその機能にはこだわりません。上級者が試行錯誤する際の労力軽減のためにウイザードやボタン積み上げ機能は望ましいと思います。

　うちの県の場合、個々の普及指導員やＪＡ営農指導員がSQLを操って技術資料の根拠にするというのはごくわずかだと思います。もともとSQLを使用した経験がほとんど無いですし、そんな慣れない作業をするくらいならs_kobayashiに相談するか、ACFinderの既存機能でエクセルファイルを出力して切り貼りするでしょう。

>　なるほど、よく使うクエリを複数のボタンに保存しておくということですね。その程度なら実装は難しくないと思います。が、現在の読み込みボタンで選択するのでも大差なく、ファイル名で選べる分選択も分かりやすいような気もします。

　繰り返しになりますが、私の提案はどちらかというと個人のスキルに依存しないACFinderの機能追加ですね。
　DBエンジンやテーブル名などの仕様が共通ですので、遠く離れた人同士が掲示板形式で意見交換したり、よりよいSQLの表現を検討したり出来ます。それはこの掲示板で行われていたこととよく似ていると思います。掲示板から自分のACFinderにデバッグ済みのSQLをコピー貼り付けして望む機能を追加する提案は多くの利用者に受け入れやすいでしょう。

>　それと、Excel で印刷までは難しいでしょうね。印刷用のフォントサイズやセル幅の設定については手動でやるしかないと思います。このツリーの中でも Excel 入れてないという人が２人いますし、用紙幅内で印刷するくらいで良いなら、反って HTML の方が向いているかな…。

　それでもいいですね。
〔283〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/15 1:30)
引用なし
   s_kobayashi さん、こん＊＊は。Hidemi Oya です。

>　おっしゃるとおり、前提条件は違うように感じます。私にとってSQL直打ちは、利用者からの緊急要望にバージョンアップで対応できない場合、開発者（あるいは上級者）がSQLを提示して暫定的に解決するというイメージです。そのSQL文を継続的に使いたい場合はボタンに覚えさせれば便利という程度で、あまりその機能にはこだわりません。上級者が試行錯誤する際の労力軽減のためにウイザードやボタン積み上げ機能は望ましいと思います。
　ということなら、同じですね。[#274] はあくまでも「簡易 SQL エディタ」に関する提案であり、通常の使い方に関しては [#276] の
>私は、基本的に SQL はなるべく使わなくてすむように、定型処理に関しては「作物・病害虫」や「農薬」タブのように、基本事項の設定だけすれば 事足りる状態にしておくのが望ましいと思います。たとえば、対象病害虫一覧や複数作物登録状況などがよく使われるとするなら、それは定型処理として専用タブ内に条件設定機能を作っておくということです。
が希望です。[#275] を読んだ時は、ユーザが SQL タブを使用することを前提として、それを如何に簡単に使えるようするかという提案のように感じたもので(^_^;)。

>　繰り返しになりますが、私の提案はどちらかというと個人のスキルに依存しないACFinderの機能追加ですね。
　何故か誤解されているような…。私の主張は上記のとおりで、s_kobayashi さんの提案と全く同じですよね？

　ただ、新しい機能が作られるたびに kabe さんはタブを増設しなければならず、ユーザは増設してもらうまで使えません。これを解決するために、下記のような機能にしてはどうかなと考えています。言葉では分かりづらいと思うので、現在サンプルを作成中です。
　ユーザは kabe さんが専用タブを増設してくれるまでこちらを利用し、kabe さんは要望の多いところから暇を見て専用タブを増設することができます。

１　ユーザインタフェース
(1) タブに「定型処理」を追加する
(2) 定型処理タブ内には、次のような機能を設置する
　a 処理内容選択機能
　b 一般的に検索条件として使われるであろう「作物名／病害虫名／用途／農薬の種類」を選択するため機能(汎用インタフェース)
２　使用方法
　ユーザは処理内容と検索条件を選択するだけで使える。
３　備考
　処理内容は検索条件を変数のようなモノに置き換えた SQL テンプレートを用意し、ユーザが選択した条件に基づいてその部分をシステムが自動的に書き換えて検索を実行する。
〔284〕Re:ACFinder 060610版
 s_kobayashi  (06/06/15 23:16)
引用なし
   ＞Hidemi Oyaさん

>　ということなら、同じですね。[#274] はあくまでも「簡易 SQL エディタ」に関する提案であり、通常の使い方に関しては [#276] の
>>私は、基本的に SQL はなるべく使わなくてすむように、定型処理に関しては「作物・病害虫」や「農薬」タブのように、基本事項の設定だけすれば 事足りる状態にしておくのが望ましいと思います。たとえば、対象病害虫一覧や複数作物登録状況などがよく使われるとするなら、それは定型処理として専用タブ内に条件設定機能を作っておくということです。
>が希望です。[#275] を読んだ時は、ユーザが SQL タブを使用することを前提として、それを如何に簡単に使えるようするかという提案のように感じたもので(^_^;)。

　わたしがちょっと思考硬直化していたかもしれません。上の文を読んで、定型処理をどんどん増やすような印象を持ってしまいました。(^^ゞ　私は複雑であまり使われない機能のタブを増やすのには抵抗があります。

　私のイメージする用途では、定型処理だけで対応できるものが２〜３割、SQL複合絞り込みもしくは手作業による二次加工が必要なものが７〜８割くらいあります。oyaさんが提案された商品名、作物名、使用前日数、使用方法の二次元リストなどはSQLの面目躍如という感じです。

　oyaさんが示された新ユーザーインターフェイスはイメージがよくつかめていませんが、モックアップが完成したらぜひトライしてみます。(^^)
〔293〕Re:ACFinder 060610版
 kabe WEB  (06/06/17 21:54)
引用なし
   ＞Hidemi Oyaさん
kabe です。

複数作物の登録確認と、対象病害虫のクロス表機能は現在、鋭意作成中です。
ただ定型処理として、どこまで汎用性を持たせるか、なかなか難しいものがあります。
明日中にはプロトタイプを一度アップしたいと思います。
〔294〕定型処理サンプル
 Hidemi Oya WEB  (06/06/18 2:12)
引用なし
   s_kobayashi さん、kabe さん、こん＊＊は。Hidemi Oya です。

　下記 URL に、定型処理タブのサンプルをあげてみました。こんな感じの処理ができれば、以前のクロス表のように SQL だけでは処理しにくい特殊な処理以外は、全部このタブに任せてしまっても良いような感じがします。
http://macs.o-ya.net/sample/

[#284] s_kobayashi さん
>　私のイメージする用途では、定型処理だけで対応できるものが２〜３割、SQL複合絞り込みもしくは手作業による二次加工が必要なものが７〜８割くらいあります。
　上のサンプルを見ていただければ分かるように、私がいう定型処理は SQL 複合絞り込みも含みます。っていうか、出来合いの SQL の基本フレームを使って、検索条件等を GUI で指定できるようにするのが「定型処理」の主眼です。
　ちなみに、手作業による二次加工がたとえば除外農薬の削除だとすれば、農薬の種類で除外農薬一覧を作成しておき、where 節に
shurui not in (<shurui>)
という一文を全てのテンプレートに入れておけば、手作業の必要はなくなります。現在は指定が面倒だけど、これなら簡単に自動化できるというような手作業は他にもいろいろあると思います。

[#293] kabe さん
>複数作物の登録確認と、対象病害虫のクロス表機能は現在、鋭意作成中です。
　ありがとうございます。いろいろ要望に対応していただいているところで申し訳ありませんが、このサンプルのような機能を実装していただけないでしょうか？ 作物名／病害虫名等の複数選択 GUI など、まだまだ開発すべき部分は多いですけど(^_^;)、この機能ができれば多くのユーザが実用的に使えるようになると思います。
〔297〕Re:定型処理サンプル
 Hidemi Oya WEB  (06/06/18 14:13)
引用なし
   　どうでも良い話なんですが、
#define {
　select ...
}
のようにインデントを付けても、SQL への変換時は行両端の無駄なスペースを削除するように若干変更しました。
  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
82 / 114 ﾂﾘｰ <前へ | 次へ>
ページ：  ┃  記事番号：   
(SS)C-BOARD vv3.8 is Free.