| |
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 を作成する必要もありませんし。
|
|
(06/06/10 14:28)
