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

研究会

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

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

〔223〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/06 0:56)
〔235〕Re:複数作物の登録状況一覧 s_kobayashi (06/06/08 23:53)
〔236〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/09 1:32)
〔237〕Re:複数作物の登録状況一覧 s_kobayashi (06/06/09 7:10)
〔240〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/09 17:48)
〔241〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/09 20:38)
〔245〕Re:複数作物の登録状況一覧 s_kobayashi (06/06/10 8:11)
〔242〕Re:フィールド名 kabe (06/06/10 5:23)
〔244〕Re:フィールド名 s_kobayashi (06/06/10 8:01)
〔246〕Re:フィールド名 s_kobayashi (06/06/10 8:20)
〔248〕Re:フィールド名 Hidemi Oya (06/06/10 15:07)
〔253〕Re:フィールド名 s_kobayashi (06/06/10 18:32)
〔257〕Re:フィールド名 Hidemi Oya (06/06/11 0:05)
〔250〕Re:フィールド名 Hidemi Oya (06/06/10 15:48)
〔247〕Re:フィールド名 Hidemi Oya (06/06/10 14:28)
〔249〕Re:フィールド名 Hidemi Oya (06/06/10 15:21)

〔223〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/06 0:56)

引用なし
    else 節が null だと order by Syurui がうまく使えなかったんですが、[#221] のように else "" にしたら order by が使えるようになりました。

select Syurui, Meisyo,
max(case when Sakumotu like "だいこん%" then Jiki||Kaisu else "" end) as Daikon,
max(case when Sakumotu like "はくさい%" then Jiki||Kaisu else "" end) as Hakusai,
max(case when Sakumotu like "キャベツ%" then Jiki||Kaisu else "" end) as Cabbege,
max(case when Sakumotu like "ブロッコリー%" then Jiki||Kaisu else "" end) Broccoli
from tekiyou where
(Syurui like "%水和剤" or Syurui like "%乳剤") and Youto like "殺虫剤" and
(Sakumotu like "だいこん%" or Sakumotu like "はくさい%" or Sakumotu like "キャベツ%" or Sakumotu like "ブロッコリー%")
group by Meisyo order by Syurui

〔235〕Re:複数作物の登録状況一覧
 s_kobayashi  (06/06/08 23:53)

引用なし
   >Hidemi Oyaさん

web上からsql文を直で打てるようにしてみました。結果はtableで返します。

http://192.168.0.56/yaku_sql.html

データベースのテーブル名やカラム名がabeさんのと違うのでそのままでは動きません。調整しても使用時期と回数がうまく表示できませんでした。

何かアドバイスをいただけたらありがたいです。

−−−−−−−−−−−−−−−−−−−−−−−−−−−
select shurui, meishou,
max(case when sakumotsumei like "だいこん%" then jiki||shiyoukaisuu else "" end) as Daikon,
max(case when sakumotsumei like "はくさい%" then jiki||shiyoukaisuu else "" end) as Hakusai,
max(case when sakumotsumei like "キャベツ%" then jiki||shiyoukaisuu else "" end) as Cabbege,
max(case when sakumotsumei like "ブロッコリー%" then jiki||shiyoukaisuu else "" end) as Broccoli
from tekiyoubu where
(shurui like "%水和剤" or shurui like "%乳剤") and youto like "殺虫剤" and
(sakumotsumei like "だいこん%" or sakumotsumei like "はくさい%" or sakumotsumei like "キャベツ%" or sakumotsumei like "ブロッコリー%")
group by meishou order by shurui
−−−−−−−−−−−−−−−−−−−−−−−−−−−

ps
このプロジェクトの中だけでも、実用化前にテーブル名やカラム名は合わせておく方が良いですね。sqlを書き換えるような不毛な努力は避けたいです。

〔236〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/09 1:32)

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

>http://192.168.0.56/yaku_sql.html
 うっ、思わずそのままクリックしてしまいました(^_^;)。
http://otori.homes.com.au/yaku_sql.html
ですね。

>調整しても使用時期と回数がうまく表示できませんでした。
 MySQL には || 演算子による文字列結合が無いようで(バージョンによるかもしれません)、jiki||shiyoukaisuu の部分を concat(jiki, shiyoukaisuu) としなければならないようです。一応、下記で大丈夫そうです。

select shurui, meishou,
max(case when sakumotsumei like "だいこん%" then concat(jiki, shiyoukaisuu) else "" end) as Daikon,
max(case when sakumotsumei like "はくさい%" then concat(jiki, shiyoukaisuu) else "" end) as Hakusai,
max(case when sakumotsumei like "キャベツ%" then concat(jiki, shiyoukaisuu) else "" end) as Cabbege,
max(case when sakumotsumei like "ブロッコリー%" then concat(jiki, shiyoukaisuu) else "" end) as Broccoli
from tekiyoubu where
(shurui like "%水和剤" or shurui like "%乳剤") and youto like "殺虫剤" and
(sakumotsumei like "だいこん%" or sakumotsumei like "はくさい%" or sakumotsumei like "キャベツ%" or sakumotsumei like "ブロッコリー%")
group by meishou order by shurui

 ところで、yaku_sql.html の「出力時カラム数」って、いちいち数えなくてはならないので不便です。結果をどのように取り出しているか分かりませんが、DBI モジュールでは必ず行の内容が配列として参照できるはずなので、その配列の要素数でカラム数は分かりますよね。出力時カラム数が無設定の場合は、自動設定してくれるとうれしいです。一番単純なのは、
@row = $sth->fetchrow_array();
$colomuns = @row;
ですかね。fetchall_arrayref でも、行要素の配列として取り出した段階で同じです。

>このプロジェクトの中だけでも、実用化前にテーブル名やカラム名は合わせておく方が良いですね。sqlを書き換えるような不毛な努力は避けたいです。
 確かに、テーブル名やフィールド名は統一しておいた方が良いかもしれませんね。ただ、今回の || と concat のように DBMS によって異なる部分があるので、いずれにしても多少の書き換えは発生すると思います。

〔237〕Re:複数作物の登録状況一覧
 s_kobayashi  (06/06/09 7:10)

引用なし
   >Hidemi Oyaさん

>>http://192.168.0.56/yaku_sql.html
> うっ、思わずそのままクリックしてしまいました(^_^;)。
>http://otori.homes.com.au/yaku_sql.html
>ですね。

 これはローカル接続時のアドレスでした。大変失礼しました。(^^ゞ

>>調整しても使用時期と回数がうまく表示できませんでした。
> MySQL には || 演算子による文字列結合が無いようで(バージョンによるかもしれません)、jiki||shiyoukaisuu の部分を concat(jiki, shiyoukaisuu) としなければならないようです。一応、下記で大丈夫そうです。

 ありがとうございます。concatってよく分かっていませんでした。

> ところで、yaku_sql.html の「出力時カラム数」って、いちいち数えなくてはならないので不便です。結果をどのように取り出しているか分かりませんが、DBI モジュールでは必ず行の内容が配列として参照できるはずなので、その配列の要素数でカラム数は分かりますよね。出力時カラム数が無設定の場合は、自動設定してくれるとうれしいです。

 これは単純に手抜きでした。(^^ゞ いつも結果をリストで取り出しているので、カラムの個数が分からなかったのです。データベースを呼び出すサブルーチンで、カラムの数も返すようにするのがいいかもしれません。

>>このプロジェクトの中だけでも、実用化前にテーブル名やカラム名は合わせておく方が良いですね。sqlを書き換えるような不毛な努力は避けたいです。
> 確かに、テーブル名やフィールド名は統一しておいた方が良いかもしれませんね。ただ、今回の || と concat のように DBMS によって異なる部分があるので、いずれにしても多少の書き換えは発生すると思います。

 私はローカル環境なので、httpdのエラーログが見えますが、普通の利用者はカラム名の間違いを自力で発見するのはとても難しいと思います。shとsyなど微妙なものも苦労しました。今回は20カ所くらい修正箇所があって、トライアンドエラーを余儀なくされました。(T.T) 名前の統一でこの苦労が無くなればアルゴリズムに意識を集中できると思います。(^^)

〔240〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/09 17:48)

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

> これは単純に手抜きでした。(^^ゞ いつも結果をリストで取り出しているので、カラムの個数が分からなかったのです。データベースを呼び出すサブルーチンで、カラムの数も返すようにするのがいいかもしれません。
 え〜と、結果をリストで取り出しているというのは、
($code, $torokunaum, $youto, $shurui, ...) = $sth->fetchrow_array();
のような左辺リストで受けているってことでしょうか? select * で検索した結果ならそれもありだと思いますが、ユーザ SQL を実行するような場合は、どのフィールドがどういう順番でいくつ現れるかが分からないので、
@row = $sth->fetchrow_array();
のように配列で受けた方が楽じゃないですか?

 ちなみに、@row をスカラーで受けて要素数にしなくても、SELECT 文実行後に
$colomns = $sth->{NUM_OF_FIELDS};
でフィールド数(というかフィールド数−1かな?)は取得できるようです。
 また、
$colomun_name[0] = $sth->$sth->{NAME}->[0];
でフィールド名も取得できます。これを使えば、結果の表頭にフィールド名を入れることも可能ですね。

> 私はローカル環境なので、httpdのエラーログが見えますが、普通の利用者はカラム名の間違いを自力で発見するのはとても難しいと思います。shとsyなど微妙なものも苦労しました。今回は20カ所くらい修正箇所があって、トライアンドエラーを余儀なくされました。(T.T) 名前の統一でこの苦労が無くなればアルゴリズムに意識を集中できると思います。(^^)
 ですね。s_kobayashi さんのフィールド名には tekiyoubyougaichuu みたいに長すぎてタイプミスを頻発しそうなのがあるので、できれば分かる範囲で短く統一するのが良いと思います。[#230] をベースに検討するってのでどうでしょう?

 ところで、登録番号がユニークであることが保証されているのに、これをプライマリーキーにしないで、kihonbu, tekiyoubu ともにオートインクリメントの code を追加しているのは何故なんでしょう?

〔241〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/09 20:38)

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

> ところで、登録番号がユニークであることが保証されているのに、これをプライマリーキーにしないで、kihonbu, tekiyoubu ともにオートインクリメントの code を追加しているのは何故なんでしょう?
 そうか、登録番号はユニークだけど、同じ登録番号で複数の登録内容が存在するからですね。

〔242〕Re:フィールド名
 kabe WEB  (06/06/10 5:23)

引用なし
   >Hidemi Oyaさん
>s_kobayashi さん 資格試験サイト活用させていただいております。

kabe です。

> ですね。s_kobayashi さんのフィールド名には tekiyoubyougaichuu みたいに長すぎてタイプミスを頻発しそうなのがあるので、できれば分かる範囲で短く統一するのが良いと思います。[#230] をベースに検討するってのでどうでしょう?
ACFinderの手元のバージョンでは次のように設定しました。
どんなもんでしょう。
登録適用部 テーブル名 tekiyou
No,Yoto,Shurui,Meisho,Tusho,Maker,Sakumotu,Basho,Byogai,Mokuteki,
Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Titai,
Noyaku,Kongo,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5
ヘボン式を基本として、一部(つ、ち)、入力に都合がよいよう勝手に解釈。
私も、どうも tsu chi よりは tu ti と打ってしまいます。

このテーブルですが、新たに Tusho(農薬通称という意味)フィールドを加えています。Meisho から屋号を抜いたフィールドです。
屋号抜き農薬名で検索できるよう次のようなビューを作成し
CREATE VIEW vTekiyou AS SELECT DISTINCT Sakumotu,Byogai,Tusho,Jiki,Baisu,Ekiryo,
Hoho,Kunjojikan,Kunjoondo,Titai,Noyaku,Kongo,
Kaisu,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5,Yoto
FROM tekiyou;
これを元に作物、病害虫の検索をするモードを付けようかなと思っています。

Kunjojikan,Kunjoondo なんですが、Hoho に入れてしまってはまずいですかね。
大本営のデータを勝手にいじるのも、どうかと思いますが、データのあるレコード数から考えると無駄なフォールドという気がします。

〔244〕Re:フィールド名
 s_kobayashi  (06/06/10 8:01)

引用なし
   >kabeさん

ご無沙汰しています。(^^)

>ACFinderの手元のバージョンでは次のように設定しました。
>どんなもんでしょう。
>登録適用部 テーブル名 tekiyou
>No,Yoto,Shurui,Meisho,Tusho,Maker,Sakumotu,Basho,Byogai,Mokuteki,
>Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Titai,
>Noyaku,Kongo,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5
>ヘボン式を基本として、一部(つ、ち)、入力に都合がよいよう勝手に解釈。
>私も、どうも tsu chi よりは tu ti と打ってしまいます。

少し直感的でないと感じる部分があったので、改善案です。

no,youto,shurui,meisho,tusho,maker,sakumotu,basho,byogaichu,mokuteki,
baisu,ekiryo,jiki,kaisu,houho,kunjojikan,kunjoondo,dojo,titai,
tekiyaku,kongo,kaisu1,kaisu2,kaisu3,kaisu4,kaisu5

改善案
(1)小文字に統一(入力労力の軽減)
(2)Byogai→byogaichu
(3)Hoho→houho
(4)Noyaku→tekiyaku(誤解を無くすため造語)

>このテーブルですが、新たに Tusho(農薬通称という意味)フィールドを加えています。Meisho から屋号を抜いたフィールドです。

これはあった方が良いですね。ニーズが高い割に、オンデマンドで処理するには負担が重いですから。

>Kunjojikan,Kunjoondo なんですが、Hoho に入れてしまってはまずいですかね。
>大本営のデータを勝手にいじるのも、どうかと思いますが、データのあるレコード数から考えると無駄なフォールドという気がします。

今はどんな使われ方をするか模索している段階なので、フィールドを減らすのは避けた方が良いでしょう。

ちょっと話は脱線しますが。

Windows環境では半角カナも特に問題はないと思いますが、linuxやhtmlなど一部の環境では半角カナは非常に取り扱いにくい場合があります。入力する際も半角カナは不便なので、できれば全角カナで取扱いするほうがいいでしょう。私の農薬検索では、データベース構築時に半角カナはunicode正規化のNFKCを掛け、さらに機種依存文字「リットル」などの置換をしています。半角英数字は変化無しです。

ACFinderでも同様の事前処理を行えば、データ内容やsql文も汎用性、共通性が高まると思います。いかがなものでしょうか。

〔245〕Re:複数作物の登録状況一覧
 s_kobayashi  (06/06/10 8:11)

引用なし
   >Hidemi Oyaさん

>> ところで、登録番号がユニークであることが保証されているのに、これをプライマリーキーにしないで、kihonbu, tekiyoubu ともにオートインクリメントの code を追加しているのは何故なんでしょう?
> そうか、登録番号はユニークだけど、同じ登録番号で複数の登録内容が存在するからですね。

 作ったときはそこまで考えていませんでした。連続したユニークな番号が保証されていると、レコードを順位付けをする場合に便利なので、1個目のカラムはオートインクリメントで番号を振るようにしています。(^^ゞ

〔246〕Re:フィールド名
 s_kobayashi  (06/06/10 8:20)

引用なし
   >改善案
>(1)小文字に統一(入力労力の軽減)
>(2)Byogai→byogaichu
>(3)Hoho→houho
>(4)Noyaku→tekiyaku(誤解を無くすため造語)

(1)小文字に統一(入力労力の軽減)
(2)Yoto→youto
(3)Byogai→byogaichu
(4)Hoho→houho
(5)Noyaku→tekiyaku(誤解を無くすため造語)

 抜けてました。(^^ゞ

〔247〕Re:フィールド名
 Hidemi Oya WEB  (06/06/10 14:28)

引用なし
   kabe さん、早朝からご苦労様です。Hidemi Oya です。

 実は、昨夜テーブル名/フィールド名統一の新スレッドを立てようと発言を書き始めたんですが、睡魔に襲われて挫折してしまいました。すでにこのスレッドで議論が始まりましたので、このスレッドが巨大化しすぎるかなという懸念はあるものの、ここで続けさせてもらいます。

>No,Yoto,Shurui,Meisho,Tusho,Maker,Sakumotu,Basho,Byogai,Mokuteki,
 Maker は、元データの「略称」のことでしょうか? 英語とローマ字のチャンポンは分かりにくいので、ローマ字に統一した方が良いと思います。下記のように、元データの一部を切り出したローマ字にするというのを原則としませんか?
登録番号→番号→bango
略称→ryakusho

>Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Titai,
 kunjojikan, kunjoondo は長いですし、他にかぶる項目もないので jikan, ondo でも良さそうです。

>ヘボン式を基本として、一部(つ、ち)、入力に都合がよいよう勝手に解釈。
>私も、どうも tsu chi よりは tu ti と打ってしまいます。
 訓令式や日本式の撥音記号(')はフィールド名としては使えませんし、長音記号は入力できませんので、ヘボン式で統一するのは賛成です。が、部分的にヘボン式以外を採用してしまうと分かりにくくなるので、これは避けた方が良いと思います。
 ただし、syo と sho、chi と ti などは慣れていないとタイプミスを頻発する可能性が高いので、表記のフレについてはフロントエンド変換で対応するってのでどうでしょう? $sql に SQL 文が入っているとして、perl で書くと以下のようなフロントエンド変換を行うってことです。動作確認はしてませんけど(mg オプションじゃなくて sg オプションの方が良いのかな)。

$sql =~ s/sy([aou])/sh\1/mg; # 部分一括変換で問題は発生しないはず
$sql =~ s/ty[aou]/ch\1/mg;
$sql =~ s/(ngo)u/\1/mg; # bangou, kongou → bango, kongo
$sql =~ s/youto/yoto/mg;
$sql =~ s/ts?uu?sho/tsusho/mg; # tusho, tuusho, tsuusho → tsusho
$sql =~ s/([iu]sho)u/\1/mg; # meishou, tsushou, ryakushou の最後の u 削除
$sql =~ s/motsu/motu/mg; # sakumotu → sakumotsu
$sql =~ s/byou?gaichuu?/byogaichu/mg; # byougauchuu, byougaichu, byogaichuu → byogaichu
$sql =~ s/suu/su/mg; # baisuu, kaisuu → baisu, kaisu
$sql =~ s/(ryo)u/\1/mg; # ekiryou → ekiyo
$sql =~ s/hou?hou?/hoho/mg; # houho, hohou, houhou → hoho
$sql =~ s/(dojo)u/\1/mg;
$sql =~ s/titai/chitai/mg;
$sql =~ s/nouya/noya/mg; # nouyaku → noyaku

>このテーブルですが、新たに Tusho(農薬通称という意味)フィールドを加えています。Meisho から屋号を抜いたフィールドです。
 どうやって屋号を抜くかはさらに検討する必要がありますが、後の利用を考えるとこれはぜひ欲しいデータですね。

>屋号抜き農薬名で検索できるよう次のようなビューを作成し
 MySQL 3.x/4.x ではビューが使えないですし、例示のような場合は必ずしもビューが必要ではないので(ビューを使うと select * from vekiyo ですむので楽ですが)、なるべくビューを使わない方がいろいろなシステムで使えて良いですね。

>Kunjojikan,Kunjoondo なんですが、Hoho に入れてしまってはまずいですかね。
>大本営のデータを勝手にいじるのも、どうかと思いますが、データのあるレコード数から考えると無駄なフォールドという気がします。
 キルパー、殺虫プレートなど使用方法が長文で、かつくん蒸時間にもデータが入っている農薬があるので、全部を使用方法に入れてしまうのはどうかと思います。くん蒸温度が入っている農薬は少ないので、くん蒸時間とくん蒸温度をひとつのフィールドにまとめるのは問題ないと思いますが…。
 SQLite は特殊なので内部保存方法がよく分かりませんが、MySQL のような一般的な DBMS では、varchar(55) のフィールドはデータがあろうがなかろうが 56 バイトの領域が確保されますが、CLOB(TEXT) フィールドなら実体へのポインタだけの領域しか使用しません。そういう意味では、データ出現頻度が少なくて varchar(3) を超えるものは CLOB(TEXT) 型(MySQL なら TINYTEXT)にした方が良いのかもしれませんね。この辺のデータを検索条件にすることはほとんどないでしょうから、検索速度向上のために INDEX を作成する必要もありませんし。

〔248〕Re:フィールド名
 Hidemi Oya WEB  (06/06/10 15:07)

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

>(1)小文字に統一(入力労力の軽減)
 テーブル名は OS によってケース依存するので、小文字統一とかに規定した方が良いですね。フィールド名は、余程特殊な DBMS でなければケース非依存なので、あまり気にする必要はないかと思いますが、私も小文字統一に一票。

>(2)Yoto→youto
>(4)Hoho→houho
 見た目の直感性ということでしょうか? これだと、meisho 等との一貫性がなくなり(houho なんかこれだけでも一貫性に欠けます)、入力時に間違える可能性が大です。結果表示の際には、フィールド名を元データの項目名で表示するようにすればフィールド名の見た目を重視する必要はないので、フィールド名はヘボン式を原則とした方が良いと思います。

>(5)Noyaku→tekiyaku(誤解を無くすため造語)
 適用地帯名を「地帯」と省略するなら、適用農薬名は「農薬」と省略しないと一貫性に欠けて分かりづらくなります。項目名とフィールド名の対応表を参照しなくてもフィールド名を入力できるようにするには、省略のしかたに一貫性を持たせるべきだと思います。
 上記同様に、結果表示時にはフィールド名を元データの項目名で表示するようにすれば問題はないと思いますが?

〔249〕Re:フィールド名
 Hidemi Oya WEB  (06/06/10 15:21)

引用なし
   > SQLite は特殊なので内部保存方法がよく分かりませんが、MySQL のような一般的な DBMS では、varchar(55) のフィールドはデータがあろうがなかろうが 56 バイトの領域が確保されますが、CLOB(TEXT) フィールドなら実体へのポインタだけの領域しか使用しません。
 MySQL では、varchar でも格納域は可変ですね。ということは、レコード内の実データとしては格納域へのポインタを持っているだけかな?
 いずれにしろ、可変長文字列型を使っていれば、データベースサイズの肥大は気にしなくても良いということになりそうです。

〔250〕Re:フィールド名
 Hidemi Oya WEB  (06/06/10 15:48)

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

>これはあった方が良いですね。ニーズが高い割に、オンデマンドで処理するには負担が重いですから。
 macs for acis のようなやり方なら、それほど負荷は高くありません。が、SQL 段階で結果を通称でグルーピングするなどができた方が便利なのは、間違いありませんね。
 ということで、このデータを持つのは大賛成なんですが、問題はどうやって屋号を削除するかです。macs for acis の tm.pm では、完全に屋号を削除できる自信は今のところありません。

>Windows環境では半角カナも特に問題はないと思いますが、linuxやhtmlなど一部の環境では半角カナは非常に取り扱いにくい場合があります。入力する際も半角カナは不便なので、できれば全角カナで取扱いするほうがいいでしょう。
 おっしゃるとおりだと思います。さらに付け加えていうなら、SQL 直書きの際に、「きゅうり」と「トマト」のようにひらがな/カタカナが混在というのも困りものです。検索条件として使用する可能性が高い適用作物名と適用病害虫雑草名については、カタカナをひらがなに変換したフィールドを追加し、検索条件は追加フィールドを使って全てひらがなで指定できるようになるとうれしいです(カタカナフィールドでも良いのですが、カタカナだと IME でひらがなからカタカナに変換するステップがひとつ増えてしまうので)。漢字→ひらがなは自動変換できないので、完全ひらがな入力はあきらめるしか無いですが…。

〔253〕Re:フィールド名
 s_kobayashi  (06/06/10 18:32)

引用なし
   >Hidemi Oyaさん

>>(1)小文字に統一(入力労力の軽減)
> テーブル名は OS によってケース依存するので、小文字統一とかに規定した方が良いですね。フィールド名は、余程特殊な DBMS でなければケース非依存なので、あまり気にする必要はないかと思いますが、私も小文字統一に一票。
>
>>(2)Yoto→youto
>>(4)Hoho→houho
> 見た目の直感性ということでしょうか? これだと、meisho 等との一貫性がなくなり(houho なんかこれだけでも一貫性に欠けます)、入力時に間違える可能性が大です。結果表示の際には、フィールド名を元データの項目名で表示するようにすればフィールド名の見た目を重視する必要はないので、フィールド名はヘボン式を原則とした方が良いと思います。

 了解しました。

>>(5)Noyaku→tekiyaku(誤解を無くすため造語)
> 適用地帯名を「地帯」と省略するなら、適用農薬名は「農薬」と省略しないと一貫性に欠けて分かりづらくなります。項目名とフィールド名の対応表を参照しなくてもフィールド名を入力できるようにするには、省略のしかたに一貫性を持たせるべきだと思います。

 ここはかなり引っかかります。省略ルールを統一してtekiti,tekinoなどにする訳にはいかないでしょうか。今後、独自のフィールド名を追加するのであればなおさら「適」から始まる省略名にしておく方が、出所が明確になっていいと思います。実際には展着剤でしか使用されないマイナーな欄ですので多少わかりにくい名前でも良いでしょう。

〔257〕Re:フィールド名
 Hidemi Oya WEB  (06/06/11 0:05)

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

> ここはかなり引っかかります。省略ルールを統一してtekiti,tekinoなどにする訳にはいかないでしょうか。
 省略のしかたに一貫性があれば、それで良いと思います。が、「適用○○」については、適用地帯名と適用農薬名の他に、適用場所/適用病害虫雑草名/適用土壌とあって、一貫性を保つためにこれら全てを teki... とするのはかなり違和感があり、本末転倒になってしまいますね。

 kabe さんが、ACFinder 060610 版で適用病害虫雑草名を byochu とされています。確かに、byogaichu ではちょっと長すぎる感はなきにしもあらずです。検索条件としてよく使用するフィールドなので、短いにこしたことはありません。
 逆に、適用農薬名は普通のクエリで使用することはまずないでしょうから、一貫性に欠けてても問題が出ることはないでしょう。

 ということで、適用病害虫雑草名と適用農薬名に限っては、例外的に一貫性のない略称を採用するってのが最も使いやすい落としどころのようですね。適用病害虫雑草名は kabe さん案の byochu、適用農薬名は s_kobayashi の第1案 tekiyaku が無難でしょうか…。

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