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

研究会

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

〔185〕ACFinder LocalDB版 kabe (06/05/31 22:51)

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

〔282〕Re:ACFinder 060610版
 s_kobayashi  (06/06/15 0:28)

引用なし
   >Hidemi Oyaさん

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

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

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

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

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

> それと、Excel で印刷までは難しいでしょうね。印刷用のフォントサイズやセル幅の設定については手動でやるしかないと思います。このツリーの中でも Excel 入れてないという人が2人いますし、用紙幅内で印刷するくらいで良いなら、反って 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 ユーザインタフェース
(1) タブに「定型処理」を追加する
(2) 定型処理タブ内には、次のような機能を設置する
 a 処理内容選択機能
 b 一般的に検索条件として使われるであろう「作物名/病害虫名/用途/農薬の種類」を選択するため機能(汎用インタフェース)
2 使用方法
 ユーザは処理内容と検索条件を選択するだけで使える。
3 備考
 処理内容は検索条件を変数のようなモノに置き換えた SQL テンプレートを用意し、ユーザが選択した条件に基づいてその部分をシステムが自動的に書き換えて検索を実行する。

〔284〕Re:ACFinder 060610版
 s_kobayashi  (06/06/15 23:16)

引用なし
   >Hidemi Oyaさん

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

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

 私のイメージする用途では、定型処理だけで対応できるものが2〜3割、SQL複合絞り込みもしくは手作業による二次加工が必要なものが7〜8割くらいあります。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 さん
> 私のイメージする用途では、定型処理だけで対応できるものが2〜3割、SQL複合絞り込みもしくは手作業による二次加工が必要なものが7〜8割くらいあります。
 上のサンプルを見ていただければ分かるように、私がいう定型処理は 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.