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

研究会

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

〔263〕作物名の数字が全角に(;_;)
 Hidemi Oya WEB  (06/06/11 10:52)

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

>作物名は前よりは融通がきくようにしていますが、検証が不十分です。
 「ぶどう(巨峰系4倍体品種)」が「ぶどう(巨峰系4倍体品種)」に変換されてしまい、検索できません。「ぶどう(2倍体欧州系品種)」等も同様です。
 とりあえず、現行のデータ保存方法では、作物名の数字は全角変換しないようにする必要がありますね。
・ツリー全体表示

〔262〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 10:28)

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

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

 正規表現が使えれば、上記の何れのケースにでも対応できる検索条件を自動的に設定することが可能です。暇が出来たら、Delphi での実装を検討してみます。
・ツリー全体表示

〔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
・ツリー全体表示

〔260〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/11 1:39)

引用なし
   要望をもう一つ追加です。

 データベース更新がかなり速くなったとはいえ、待ち時間いらずというわけにはいきません。SQLite はデータベースファイルを共有しても問題なく使用できるように作られているようなので、事務所で使うような場合は、基本設定にデータベースパスを追加して、データベースファイルを共有できると良いですね。これだと、誰かが更新すれば、他の人は更新しなくてすみます。
 システム全体をサーバにおいて共有すれば、上記のような設定は不要になりますが、確か農薬ナビ版や農薬検査所版ではこういう使い方はできませんでした。試してないけど、今バージョンは大丈夫なのかな?
・ツリー全体表示

〔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
・ツリー全体表示

〔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
・ツリー全体表示

〔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 が無難でしょうか…。
・ツリー全体表示

〔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
・ツリー全体表示

〔255〕Re:ACFinder 060610版
 Hidemi Oya WEB  (06/06/10 23:05)

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

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

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

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

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

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

 通称対応版複数作物登録一覧を試している際に、もうひとつ気が付いた点があります。今バージョンでは、
max(case when sakumotsu like "だいこん%" then jiki||kaisu else "" end) だいこん
のようにフィールドエリアスに日本語を使ってもエラーにならなくなりましたが、AS を付けてもシングルクォートやダブルクォートで括ってみても、ヘッダにフィールド名が表示されません。これで、ヘッダに日本語が表示されるようになれば完璧です。
・ツリー全体表示

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

ですが、作物、病害虫検索については独自にビューを作成して検索しています。
・ツリー全体表示

〔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などにする訳にはいかないでしょうか。今後、独自のフィールド名を追加するのであればなおさら「適」から始まる省略名にしておく方が、出所が明確になっていいと思います。実際には展着剤でしか使用されないマイナーな欄ですので多少わかりにくい名前でも良いでしょう。
・ツリー全体表示

〔252〕Re:ACFinder LocalDB版
 Hidemi Oya WEB  (06/06/10 18:08)

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

>ただ自動プロキシのスクリプト解釈をACFinderに付けるのは多分難しいです。
 自動構成スクリプトの場合、起動時にスクリプトを実行して、レジストリにプロクシの設定が書き込まれると思ってたんですが、レジストリに保存しないで接続のたびにスクリプトを実行してるんでしょうか?
 だとすると、WPAD による自動検出(DHCP や DNS の情報を使ってスクリプトサーバを自動的に探す)でも設定には同じスクリプトを用いるので、レジストリにプロクシ設定が書き込まれる可能性は皆無ですね。

>うちの県も、以前は自動プロキシだったのですが、いつの頃からか無くなってしまいました。
 自動構成スクリプトだったのが自動検出になったということでしょうか?

 いずれにしても、自動検出や自動構成でレジストリの
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\WinHttpSettings
に設定が保存されているかどうかを確認してみる必要があると思います。で、どこにも保存されていなければ、自動検出や自動構成を実行するのがベストかと…。WinINet または WinHTTP の API に直接実行できる関数があれば楽ですが、まだそこまで探せていません。
・ツリー全体表示

〔251〕ACFinder 要望追加
 Hidemi Oya WEB  (06/06/10 17:33)

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

 昨夜母ちゃん(同業者です)に頼まれて、複数作物の登録状況一覧を作成して CSV ファイルに保存して気づいたんですが、CSV の先頭にフィールド名が付かないんですね。StringGrid のヘッダにはフィールド名または項目名が表示されるようになっているので、CSV にも先頭に付けてもらえるとありがたいです。
・ツリー全体表示

〔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 でひらがなからカタカナに変換するステップがひとつ増えてしまうので)。漢字→ひらがなは自動変換できないので、完全ひらがな入力はあきらめるしか無いですが…。
・ツリー全体表示

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

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

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

〔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 を作成する必要もありませんし。
・ツリー全体表示

〔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(誤解を無くすため造語)

 抜けてました。(^^ゞ
・ツリー全体表示

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

引用なし
   >Hidemi Oyaさん

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

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

〔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文も汎用性、共通性が高まると思います。いかがなものでしょうか。
・ツリー全体表示

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