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

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
82 / 114 ﾂﾘｰ <前へ | 次へ>
〔185〕ACFinder LocalDB版 kabe (06/05/31 22:51)
〔209〕Re:ACFinder LocalDB版 kabe (06/06/04 22:28)
〔214〕Re:ACFinder LocalDB版 Hidemi Oya (06/06/05 1:42)
〔218〕複数作物の登録状況一覧 Hidemi Oya (06/06/05 23:28)
〔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)
〔225〕Re:複数作物の登録状況一覧 kabe (06/06/06 22:43)
〔227〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/06 23:45)
〔230〕Re:複数作物の登録状況一覧 kabe (06/06/07 21:32)
〔231〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/07 23:58)
〔234〕Re:複数作物の登録状況一覧 Hidemi Oya (06/06/08 1:02)
〔209〕Re:ACFinder LocalDB版
 kabe WEB  (06/06/04 22:28)
引用なし
   ＞Hidemi Oyaさん

>[#184] のような列数固定の表なら SELECT 文だけでいけそうだと思って取り組んでみたんですが、サブクエリの書き方が分からない…(^_^;)。
「SQL クロス集計」で検索してみました。
イメージ的には次のようなSQLでいけそうです。（内容が正しいかどうか不明）
SELECT Meisyo ,
MAX(CASE WHEN Sakumotu = "きゅうり" THEN Jiki||Kaisu ELSE NULL END) AS KYURI ,
MAX(CASE WHEN Sakumotu = "ﾄﾏﾄ" THEN Jiki||Kaisu ELSE NULL END) AS TOMATO
FROM
(SELECT Meisyo,Sakumotu,Jiki,Kaisu FROM tekiyou WHERE (Sakumotu LIKE "きゅうり" OR Sakumotu LIKE "ﾄﾏﾄ") AND No IN
(SELECT No FROM tekiyou WHERE Meisyo LIKE "ﾀﾞｺﾆｰﾙ%" OR Meisyo LIKE "ﾄｯﾌﾟｼﾞﾝ%")
)
GROUP BY Meisyo

>　それはそれとして、クロス表はすでにできていたルーチンを使って実装できないんでしょうか？
SQLにこだわるよりは、こちらの方が簡単そうなので、そのうち入れます。

Excel なしのCSV変換はなんとかできそうです。
〔214〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/05 1:42)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>イメージ的には次のようなSQLでいけそうです。（内容が正しいかどうか不明）
　おお〜、良い感じです！ サブクエリ使っても思ったより速いですね。農薬名のところを Sakumotu で「きゅうり」と「ﾄﾏﾄ」にすれば、全農薬もいけそうです。とりあえず、２作物だけなら全農薬でも十分高速でした。

>SQLにこだわるよりは、こちらの方が簡単そうなので、そのうち入れます。
　上ができれば、フィールド数固定なら SELECT だけでいけるなと思ったら、すでに [#212] が書かれてますね。こちらも実に良い感じです。
　が、従来のクロス表のように全ての病害虫を一覧にするのは SELECT 文だけでは無理なので、従来版も実装してもらえると助かります。

　で、これらを試してみてて気づいた点…。
　SQL テキストボックスの行数が増えてもスクロールバーが出てこないのがちょっと辛いです。SQL テキストボックスは条件消去でクリアされないのもちょっと辛いです。ツールバーのボタンはマウスの移動距離も大きいので、テキストボックスの脇に「消去」と「実行」ボタンがあると良いですね。
　AS で作るフィールド名に日本語が指定できると良いですね。今は、LIKE とか = とかの演算子の右側の文字列リテラルだけコード変換してるのでしょうか？ SQL 文全体を Shift-JIS -> UTF-8 変換するんじゃダメなのかなあ…。
　基本となるクエリ式は同じで、作物名／病害虫名／農薬名等の条件だけを変更したいという用途は多いと思います。これを支援するような機能があるとうれしいですね。どんな方法がよいかは検討の余地がありますが、たとえば下記のようにリストを条件式に展開するようなマクロが作れれば、マクロに渡すリストを変更するだけで簡単に条件変更できるようになります。マクロなら文字列置換だけで実装できそうなので楽かも…。

$sakumotu = 'Sakumotu, or, きゅうり% ﾄﾏﾄ%'
select Meisho from tekiyo where $sakumotu
// 先頭が $ ならマクロとしてデータを保存するだけでクエリを発行しない
// $sakumotu を「Sakumotu like 'きゅうり%' or Sakumotu like 'ﾄﾏﾄ%'」に展開してクエリを発行

>Excel なしのCSV変換はなんとかできそうです。
　こちらができれば、不可視の StringGrid にデータを入れて、そのデータから直接 INSERT 文を発行することでデータベース作成の高速化も可能かもしれませんね。
〔218〕複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/05 23:28)
引用なし
   　指定作物の全農薬リストは、下記のようにサブクエリ無し集約関数のみで実現できました。農薬数が多くなりすぎるのと使い勝手を考えて、農薬の種類が "%水和剤" または "%乳剤" で、かつ用途が "殺虫剤" のみのものに限定しています。４作物全農薬でも結構高速です。

select Syurui, Meisyo,
max(case when Sakumotu like "だいこん%" then Jiki||Kaisu else null end) as Daikon,
max(case when Sakumotu like "はくさい%" then Jiki||Kaisu else null end) as Hakusai,
max(case when Sakumotu like "ｷｬﾍﾞﾂ%" then Jiki||Kaisu else null end) as Cabbege,
max(case when Sakumotu like "ﾌﾞﾛｯｺﾘｰ%" then Jiki||Kaisu else null end) as 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

　いやしかし、やっぱり作物リストを指定するだけで SQL に展開してくれるような支援機能が欲しいですね。[#214] のような文字列マクロじゃ、case 文の生成は無理なのであまり意味がないですね(^_^;)。
　VIEW とか PRAGMA を使っても無理なのかなあ…。

　話は変わりますが、フィールド名で、表記は "う" だけど読みは長音記号として使われる "う" が、Youto のように "u" が付いていたり、Meisyo のように "u" が省略されていたりするのは非常に分かりづらいので、どちらかに統一した方が良いと思います。それと、syu, syo などを指が勝手に shu, sho と打ってしまい、しょっちゅうエラーを出してます(^_^;)。
　フィールド名に日本語を使用するか、Meisyou でも Meisho でも使えるようにエリアスを設定してもらえると良さそうです。
〔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
〔225〕Re:複数作物の登録状況一覧
 kabe WEB  (06/06/06 22:43)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　指定作物の全農薬リストは、下記のようにサブクエリ無し集約関数のみで実現できました。
なるほど。サブクエリで作成した表を元にして転置しなきゃダメかなと思ったのですが、この方が簡単ですね。

>　いやしかし、やっぱり作物リストを指定するだけで SQL に展開してくれるような支援機能が欲しいですね。
SQL文さえわかれば、インターフェース部分はなんとかなると思います。

>　フィールド名に日本語を使用するか、Meisyou でも Meisho でも使えるようにエリアスを設定してもらえると良さそうです。
フィールド名は日本語、ローマ字どちらがよいでしょう。
エリアスというのはデータベース側に設定できるのですか。
〔227〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/06 23:45)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>SQL文さえわかれば、インターフェース部分はなんとかなると思います。
　よろしくお願いします。
　用途固定なら専用 UI もありだと思いますが、DMonkey 等でスクリプトマクロが使えると汎用的に使えて便利かもしれませんね(さらにマニアックな機能になってしまいますが^^;)。将来の拡張機能のひとつとしてご検討いただければと思います。
http://sourceforge.jp/projects/dmonkey/

>フィールド名は日本語、ローマ字どちらがよいでしょう。
　個人的にはフィールド名に日本語を使うのは好きではありませんが、いろんな人が使うことを考えると、日本語の方が取っつきやすいかもしれませんね。ローマ字は表記のフレの問題もあるので、日本語でなければ英語が良いかも…。

>エリアスというのはデータベース側に設定できるのですか。
　と思うのですが、やり方はよく分かりません(^_^;)。フィールド定義時に AS を使うのかなあ？
〔230〕Re:複数作物の登録状況一覧
 kabe WEB  (06/06/07 21:32)
引用なし
   ＞Hidemi Oyaさん

kabe です。

>　用途固定なら専用 UI もありだと思いますが、DMonkey 等でスクリプトマクロが使えると汎用的に使えて便利かもしれませんね
う〜ん。私には難易度が高そう。

>　個人的にはフィールド名に日本語を使うのは好きではありませんが、いろんな人が使うことを考えると、日本語の方が取っつきやすいかもしれませんね。ローマ字は表記のフレの問題もあるので、日本語でなければ英語が良いかも…。
安易なんですが、自分ではローマ字が使いやすいですね。
ヘボン式ローマ字に統一しようと思います。
これでどうでしょう。
No,Yoto,Shurui,Meisho,Maker,Sakumotsu,Basho,Byogai,Mokuteki,
Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Chitai,
Noyaku,Kongo,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5

>>エリアスというのはデータベース側に設定できるのですか。
>　と思うのですが、やり方はよく分かりません(^_^;)。フィールド定義時に AS を使うのかなあ？
SQLを実行する前にフィールド名を置換するのであればできそうです。
根本的にユーザーにフィールド名を自由に設定してもらうという手もありですが…
〔231〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/07 23:58)
引用なし
   kabe さん、こん＊＊は。Hidemi Oya です。

>う〜ん。私には難易度が高そう。
　ま、あくまでも将来の拡張機能のひとつってことで…。

>ヘボン式ローマ字に統一しようと思います。
>これでどうでしょう。
>No,Yoto,Shurui,Meisho,Maker,Sakumotsu,Basho,Byogai,Mokuteki,
>Baisu,Ekiryo,Jiki,Kaisu,Hoho,kunjojikan,kunjoondo,Dojo,Chitai,
>Noyaku,Kongo,Kaisu1,Kaisu2,Kaisu3,Kaisu4,Kaisu5
　私自身はローマ字を使う時はヘボン式なので(タイプ数が少ないですから)大歓迎なんですが、これはこれでなれてない人が使うのは不便かもって感じもします。

>SQLを実行する前にフィールド名を置換するのであればできそうです。
　テーブル定義時にフィールドの別名を設定するのは無理っぽいですね。ということで、Delphi 側で 'sy' -> 'sh', 'ou' -> 'o', 'uu' -> 'u' の変換をしてやるのが一番簡単そうです。

>根本的にユーザーにフィールド名を自由に設定してもらうという手もありですが…
　テーブル別のフィールド番号／フィールド名対比表を持っていれば、ユーザが名前を付けても問題はないわけですね。ということは、INI ファイルにデフォルトでヘボン式ローマ字を記述しておき、必要に応じて書き換えてもらうのが一番自由度が高いかな。ただ、書き換える場合は、テーブルを作る前に書き換えてもらう必要がありますかね。
〔234〕Re:複数作物の登録状況一覧
 Hidemi Oya WEB  (06/06/08 1:02)
引用なし
   >　私自身はローマ字を使う時はヘボン式なので(タイプ数が少ないですから)大歓迎なんですが、これはこれでなれてない人が使うのは不便かもって感じもします。
　しまった、「ち」と「つ」は日本式ローマ字のちゃんぽんで使ってました(なぜならば、タイプ数が少ないから)。今回は関係ないけど、ヘボン式ローマ字では「ぢ」と「づ」は表現できないので、これは日本式を使わざるを得ませんね。
　ってことで、デフォルトヘボン式で、ユーザ自由設定方式が一番良いかもしれません。
〔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
−−−−−−−−−−−−−−−−−−−−−−−−−−−

ｐｓ
このプロジェクトの中だけでも、実用化前にテーブル名やカラム名は合わせておく方が良いですね。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など微妙なものも苦労しました。今回は２０カ所くらい修正箇所があって、トライアンドエラーを余儀なくされました。(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};
でフィールド数(というかフィールド数−１かな？)は取得できるようです。
　また、
$colomun_name[0] = $sth->$sth->{NAME}->[0];
でフィールド名も取得できます。これを使えば、結果の表頭にフィールド名を入れることも可能ですね。

>　私はローカル環境なので、httpdのエラーログが見えますが、普通の利用者はカラム名の間違いを自力で発見するのはとても難しいと思います。shとsyなど微妙なものも苦労しました。今回は２０カ所くらい修正箇所があって、トライアンドエラーを余儀なくされました。(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

改善案
（１）小文字に統一（入力労力の軽減）
（２）Byogai→byogaichu
（３）Hoho→houho
（４）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 を追加しているのは何故なんでしょう？
>　そうか、登録番号はユニークだけど、同じ登録番号で複数の登録内容が存在するからですね。

　作ったときはそこまで考えていませんでした。連続したユニークな番号が保証されていると、レコードを順位付けをする場合に便利なので、１個目のカラムはオートインクリメントで番号を振るようにしています。(^^ゞ
〔246〕Re:フィールド名
 s_kobayashi  (06/06/10 8:20)
引用なし
   >改善案
>（１）小文字に統一（入力労力の軽減）
>（２）Byogai→byogaichu
>（３）Hoho→houho
>（４）Noyaku→tekiyaku（誤解を無くすため造語）

（１）小文字に統一（入力労力の軽減）
（２）Yoto→youto
（３）Byogai→byogaichu
（４）Hoho→houho
（５）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 です。

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

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

>（５）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さん

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

　了解しました。

>>（５）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 の第１案 tekiyaku が無難でしょうか…。
  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
82 / 114 ﾂﾘｰ <前へ | 次へ>
ページ：  ┃  記事番号：   
(SS)C-BOARD vv3.8 is Free.