木燃人の波止場

花やお寺や観光地の写真を紹介しつつ、皆さんとの交流を計りたく思ってます、気軽に見て戴き、コメントを戴ければ嬉しいです。

SQLで四苦八苦 -3 (No 2179)

2020-01-22 08:00:00 | パソコン

 私の作る「花写真鑑」などの、各種資料をデーターベース(DBと略す)にして、花の名前を調べたりするための手段の一つにしようと考え、DBの作成と、それをウエブ上で「あいまい検索」などが出来るようにしようとして、四苦八苦している。 

 心身ともに老化現象の激しい私にはこの作業が大変難しく、何冊もの本や、友の助けをもらいながら、極めてのろのろであり、また、後戻りもあるが、最近になり、ほんの少しずつ前進しているように見えるので、備忘録を兼ねて、そこら辺りを書き止めたいと考えた。

 

 いままでの歩み・・・・

 1. Java Script  (最初に取り組んだ)             ブログNo
 2. 目標     (改めて具体化した)
 3. やる範囲   (目標の一部でもある)     以上 「暗中模索 -1」No2149
 4. PHPとMySQL (試行結果の初期)
 5. DB と SQL  (正に暗中模索)         以上 「暗中模索 -2」No2150
 6. SQL Server (DBの名前付けたが?)           「暗中模索 -3」No2151
 7. サーバー   (サーバーはいずこに?)
 8. SQL Server へのデーター書き込み       以上「暗中模索 -4」No2152
 9. 再びPHPとMySQL              「四苦八苦 -1」No2174
 10.プラウザの比較(試用を含む)
 11. Apacheの再インストール        以上「四苦八苦 -2」No2176

 今回はこの続編になる。

 

12. DBは何とか出来たようだが・・・?

 「花写真鑑」関連としては、従来Excelで作成していたものをDB化する
   ① 花名登録原表 一種類毎の登録原表 現在花(植物)は、1812種類あり。
   ② 花登録別名表 花にはいくつかの名前があり、その名前から探す場合などに使う。
            上記1812種の各花につき、合計3756の花名を集録している。

 従来この「花写真鑑」に登録していなかった花(以後"新種"とす)を見付けた時、登録済みか否かを調べるなど、日常私自身の必要性から、考えたものであるが、当面この二表をDBとすべく、取り組んだのである。

 途中、何度も止めようかとも思ったほどに、難しく難航したが、2020.01.03 上記二表がようやく出来上がった。 形は出来たが、今までの体験から、DBとは一筋縄では行かないようなので、改造もしくは造り変えがあり得るが、一応の帰結を見た。 

 

13. DB化とは、四苦八苦そのものだ(体験から)

 13.1 Excelなどは、画面にそのものが現れるから、そこを見ながら、如何様にも変えられるし、年々お節介とも思われるほどに、色々なことが出来るが、その辺りは、DBとはえらい違いで、全体は見られるが、そのままでは無く、完全に加工されたものなので、直接的修正などは出来無い。

 13.2 よって、数の多い修正は非常に手間が掛るので、私は一旦全て消して、原稿となるExcelを修正したあとで、改めて正しいのと入れ替えることにしたほどである。 データーの修正なども、命令文を書かねばならない、つまり、プログラミングしなければならないのである。

 13.3 4000近いデーターも、Excelからコピー出来る事は前に書いた。そのExcel表上見た目には解らないが、そのデーターが、例えば最初が、数字の”1”であったものを、”0001”にした場合、ご親切にも、その痕跡までがExcelには残っていて、それが悪さをする(エラーになる)ことがわかった。

 13.4 また、Excelでは、文字を半角で書いても、全角でかいても、検索、並べ替えには支障なく同レベルの扱いになるが、DBでは別の扱い(別の文字)になり、混合している場合は、修正しないと、検索や並べ替えから、こぼれ落ちることになる。

 13.5 DBデーターは、メモリー消費量が異常に大きい(?)
         DB列数 データー数  Excel     DB
① 花名登録原表   5     1812   423KB/2    384KB 
② 花登録別名表  7     3756   730KB/2   9216KB

 作業としては、①を最初にDB化しようとするが、何故かエラーになり、何度やっても同じなので、一旦諦めて、②をDB化したら、理由は不明なれど、すんなりと出来た。しかし、この時はExcelからのコピペに30分程要した。次いで①をコピペしたら、10分ほど要した。(Excelは二枚の表のKB数)

 その後、②を再度試みたところ、5分もかからずにコピペが出来た。これらの出来事から、私の独断と偏見に充ち満ちたものであるが、次のように考えると、この現象が説明できるように思えたのであった。

 a、上記①と②のデーターは、内3(列)が全く同じであり、これをDB上では二つでは無くひとつ(同じ)と記録したのではないか?。そう考えると、最初は時間が掛ったが、二回目は早くなった事が説明出来るのである。

 b. 例えばWindowsなどでは、同じ表名もホルダーが異なれば、同じでは無いと考えるようであるが、DBの世界(MySQLやPHPなども含む)では、ホルダーに関係なく、"同じ物は同じ"とする、極、当たり前のことが行われているように思える。「階層」と言う階段を無視出来るメリットが生じる。

 c。 このようにDBはメモリーの消費量が格段に大きいことがわかり、一方サーバーについてであるが、Microsoftが無料で提供している、DBサーバーは10MBであり、既に上記①②でいっぱいとなり、プログラム所か、データーの一部が消えるなどが、発生して身動きが取れなくなる恐れあり。

 また、私がレンタルしているプロバイダーの当初DB容量は50MBであるから、まだまだ余裕あるように見えるが、この他にプログラムなどもあるし、DBは大飯食らいと解った今は、簡単には踏み切れない。要は先が見通せ無くなってきた。これは金を出せば、いくらでも増やせるが、それほどのメリットも感じないのである。

  13.6  パスワード(PWと略す)について

 上記の如く、メモリー消費量が大きいことが判明したので、私のDBは一般公開するには至らない可能性がでてきたので、データーの安全性には余裕みたいなものができたので、より簡単となる(・・・と思っただけだった)ので、最初はPW無しで、DB作成を始めた。

 しかし、やって見ると、世の中ではDBは一般公開が原則となっているようで、PW無しのサンプルや私の教科書となる資料となる物が無く、また、PHPでテストして見ると、動かないのであった。 そこで、上記の如くPW付きでやったら、まだ本格的ではないが、PHPが何とか動くようになった。

 13.7 文字化けの発生

 最近の文字コードは、「UTF8」が標準的になっていることは、承知しているが、私の場合はかなり古くからであり、「Shift JIS」を使い続けているが、今回DBを始めるにあたり、変えるか否か悩んだが、これから変えるとして、「UTF8」で始めた。

 昨日(2020.01.03)午前中までは、異常無かったが、 午後から文字化けが始まった。これは、当然予測できたことではあるが、これから変えてゆくきっかけになるかと思ったが、そんな考えは甘く、今更全体を変えることは、極めて不合理であり、DBを「Shift JIS」作り変えるしかないと判断した。

 

 まだまだ、苦悩はつづくが、空っぽの頭を振り回し"まくる"から、首や頭が痛くなるので、ここで一休みとする。

 

                                  つづく

 

 

 

 

コメント   この記事についてブログを書く
« コーヒークラブ (No 2183) | トップ | お好み焼き本舗 (No 2184) »
最新の画像もっと見る

コメントを投稿

パソコン」カテゴリの最新記事