DB版プロフィールメーカー3【データアップロード】

さぁて、今日からは純粋に世界レベルのサッカーを楽しめそうです・・・寝られない（笑）。

さて、今日は「データアップロード（MySQL　PostgreSQL）」のお話。たくさんのデータがあれば。それを入力する労力も半端ではないわけで、いかにして入力するかが重要ですね。

入力する人がたくさんいて、それぞれが自分の管轄のみを入力するというのが一つの方法でしょう。先日お話しした「カテゴリ毎に管理人がいる」場合がこれに属すると思います。
管理人が一人だったら・・・入力フォームにいちいち入力して行くのは気が遠くなるかも知れません。そういう場合は、決まった形式のテキストデータファイルを用意して、一挙に更新した方が効率がいいでしょう。DB版プロフィールメーカーでは、タブ区切りのテキストデータをアップロードして、全件一度に更新することが可能です。詳しい形式についてはここではお話ししませんが、実際のファイルはこんな感じです。これをアップすると↓のような確認画面が出た後、実際に更新となります（サンプルでは、実際に更新するスクリプトは省いてありますので、お試しいただけません）。



サンプルのデータも自動作成させたテキストデータをアップロードして入力してますよ。私一人ではとてもやってられませんから（笑）！

DB版プロフィールメーカー2【カテゴリその２】

「カテゴリ毎の編集が独立している」と昨日言いましたが、一部ウソがあります。例えば、カテゴリ編集のプロフィール編集で所属カテゴリを変えられたり・・・他にもいくつかあります。これは完全独立に設計すべきかどうかは使う人によるわけで、カスタマイズ使用が前提のものでそうはっきり決めることもないんじゃないの～、ってことで曖昧にしてあります。具体的にお客様のご希望を伺った上で、足すなり引くなりすればいいでしょう。

さて、今日はカテゴリの削除について（MySQL　PostgreSQL）。削除はね・・・単純にはカテゴリに属する全データをばっさり消しちゃえばいいんでしょうけど、数が多いんでそう思い切っていいものかと・・・（笑）。カテゴリは消したいけどデータは残したい・・・なんてケースがあるかわかりませんが、一応データは他のカテゴリに移動させることが出来るようにしてあります。実は、これが出来ると「カテゴリの結合」が出来るんで、そういった面で有用かと。もちろん、結合した後元に戻すとなるとえっらい大変なので、慎重に使わないと楽するつもりがかえって・・・なんてありがちですけどねっ。

DB版プロフィールメーカー2【カテゴリ】

たくさんのデータを管理する上で、カテゴリ（グループ）分けはどうしても必要になるでしょうね・・・ただ、カテゴリの中にまたカテゴリ・・・といくつも階層を深くして行けるのがいいかというとまた別問題ですね。webアプリケーションだとインターフェイスが限られますから、一生懸命分類するほど探しにくくなる場合もあります。

スタンダード版としましては、１階層までのカテゴリ分けを実装しています。トップページの見た目こそフラットな管理に見えますが、カテゴリ一覧（MySQL　PostgreSQL）でいくつでもカテゴリを作成可能です。カテゴリ毎の登録数が人間の手に負える件数なら、素早くアクセス可能になると思います。もちろん。カテゴリ内での検索も出来ますので、件数が多くて困るということはありません。

カテゴリ一覧からは、カテゴリ毎の編集画面（MySQL　PostgreSQL）に行けるようになっていますが、この時、１カテゴリに１ウィンドウを開き、そのウィンドウ内で各カテゴリの管理・編集が完結するようにしてあります。つまり、「カテゴリ毎の編集が独立している」ということにいなりますが、これには重要な意味があることにお気づきでしょうか？一人の管理人が、こっちのグループを変更して、あっちのグループを変更して・・・といった作業を並行して行うにも都合がいいですが、それよりもっと重要なのは、「カテゴリ毎に決められた複数の担当者（管理人）によって管理・編集が出来る」ということです。

個々のデータは共通の性格を持つもののグループ同士は独立というケースは非常に多いと思います。例えば、

１企業　→　店舗１，店舗２・・・・
１スポーツリーグ　→　チーム１，チーム２・・・

とか。細かい事情はいろいろあると思いますが、いずれもグループ管理がで効率的、もしくはグループ管理でなければダメなというケースが想定されるでしょう。もちろん、本当の意味で独立にするためには、カテゴリ毎に管理パスワードを分けられなければなりませんが、そこから先はカスタマイズということで、ご希望に応じて対応させていただきたいと思います。

DB版プロフィールメーカー1

さて、まずはDB版プロフィールメーカーのお話です。MySQL版とPostgreSQL版をご用意しております。もちろん、機能に違いはありません。世間的には、MySQLを好まれる方が多いんですかね・・・うちのお客様の傾向としてもそんな感じですが。

変な名前が並んでると思いますが、ひらがな３文字をランダムに選んで1,000件のデータを自動作成してますんで、あり得ない名前がほとんどだと思います。一応、たくさんのデータが入ってないとDB版サンプルとしての意味がないですし、手入力なんてしてたらシャレになりませんので・・・。

トップページは、PHP版と同じような感じですね。開発の流れとしては、PHP版に「データ件数が多い場合に必要とされる機能」を付け加えていったという感じだったと思います。

名前は、新しいもの順に表示されるようになっていますので、新規作成すると必ずトップページの先頭に現れます。最近登録したものほど更新頻度が高いと想定した仕様です。まぁ、古いもの順でソートを付けても構いませんが、今のところは付けてません。

データを指定件数毎に分けて表示する機能は必須ですね。最近登録したデータなら何ページかめくればたどり着けるでしょう。

目的のデータが最近のものでなかったり、どこにあるかわからない場合は、いちいちページをめくっていては日が暮れますね。当然、検索も標準で搭載しています。

今回は第１弾ということで、ざっとこのくらいにしておきましょうかね。次回からは個別に機能を見ていくことにしましょう。

安サーバへの挑戦？

今使ってるzonch.netのサーバってデータベースが一個しか使えない。サポートに「無制限とは言いませんのでいくつか使えるようになりませんかねぇ？」なんて言ってみたら、「テーブル名がぶつからないように変えてお使いください」だって・・・そんなんわかってるってば・・・そうしたくないから訊いたのに・・・。

年間2,400円のXREAだって５個まで使えるというのにぃ！ドメイン取ったって3,300円だ・・・というわけで、借りてみましたXREA。ドメイン（office-zonch）取って。

XREAのように安くて何でもありってサーバは確かに魅力的だよね。年3,300円で済んで特に問題なしならこんなにありがたいことはないでしょう。仕事で使うサーバじゃなかったら、何の迷いもなく決まりです。

安サーバで気になるのは、安さ故に１サーバあたりのユーザー数は多いと想像され、どんな悪さをするユーザーと同じサーバになるかわからないということ・・・もちろん安くなくたってそうした心配はあるので、あくまで確率の問題です。

でもまぁ、２４時間お客様にサービスを提供するサーバではなく、とりあえず公開用そして個別のお客様にお見せする「サンプル」を動かすだけが目的なので、常時パフォーマンスが出ている必要はないわけです。おまけにzonch.netのサーバではMySQLだけなのにPostgreSQLまで使えるときたもんだ！おいしい・・・実においしい。

ただ、サーバのレスポンスが悪ければ、「ここのプログラム重いんじゃないの？」などと誤解されてしまう危険もあるわけで（笑）。う～ん、そうなるとかなり困るかも・・・まぁ、とりあえずしばらくはこれで様子見です。

実際に動かしてみた感想としましては、ちょっとレスポンス悪いかなって時はありますね。でも、これはサーバが原因とも言い切れないので、何とも言えないです。ひどく重いというほどのことは今のところは経験してません。値段を考えれば、素晴らしい働きといえるでしょう（もちろん、ページを見た人はどんなサーバで動いてるかなんて考えたりしないので、評価が違ってくるかも知れませんが・・・）。

DB版プロフィール＆スケジュールメーカー

「PHP+DBに力入れてます！」なんて書いていたのは去年だったのね・・・それっきり音沙汰ないと力入れてないみたいですが、むしろその逆です。オリジナルあるいはカスタマイズのデータベースシステムの製作が入って、なかなかそれ以外の時間が取れなくなってました。データベースシステムって小規模ってことはあり得ないので、１件あたり数ヶ月の開発期間なんてこともありますし、それが２～３件重なってきたりして、もう「えらいこっちゃ！」になってました。

というわけでして、力入れてないのではありません。「力入れまくり」です（笑）。

カスタマイズの場合のベースとなる、プロフィールメーカーやスケジュールメーカーのデータベース版も、とうの昔にあったのですが、皆様にご紹介出来ずにおりました。個別にお問い合わせいただいたお客様にはご提供しておりましたが・・・（上記のカスタマイズというのはそういうことです・・・）。
でもまぁ、決まった形のものをそのまま販売するつもりもないので、ベースとなるものはその時々でいろいろ変わっていくと思います。ですから、これからご紹介するものも現時点で形になっているだけのもので「一例」にすぎないかも知れませんが、「ここをあぁして欲しい」「あそこは別のものがいい」などと考える上でのリファレンスにでもなれば、それはそれで有意義かなと思います。

では、次回より具体的にお話ししていくことにしましょう。

PHP版プロフィールメーカー5

PHP版プロフィールメーカーは、CGI版と同価格の6,000円で販売いたします。PHP版が欲しい～って方はこちらをどうぞ。

でも、CGI版、PHP版どっちがいいの～？・・・なんて声が聞こえてきそうですので、私なりに選ぶ基準をまとめてみますと・・・

１，好み。好きならそれでいいじゃない（笑）。出来ることに違いはありませんので。あとは、これまでにお話しした仕様の違いも含めて「好み」ですね。

２，近いうち、あるいは将来的にでもデータベースを利用したカスタマイズをされる予定があるんでしたら、PHP版で決まりです。Perlでのデータベースはお受けしておりませんので。

とまぁ、こんな感じですかね。テンプレートにも違いはありませんので、ページデザインの面でもどちらを選ばれても構わないと思います。

PHP版プロフィールメーカー4

CGI版とPHP版との違い・・・を見ていく前に、実物はこちら。
CGI版　PHP版
パスワードは、共に「zonch」っす。

では、違いです。
１，CGI版は更新時にhtml作成。PHP版は表示の度に作成。
　これについては前回お話しましたね。プロフィールページだけでなく一覧ページも同様です。

２，CGI版には全ページ更新がありますが、PHP版にはありません。
　これは１とも大いに関連があります。まず、全ページ更新というのは、「プロフィールページを全て一度に更新する」処理のことです。なぜこれが必要かと言いますと、ページ作成後にテンプレートを書き換えた場合、それに合わせて作成済みの全てのページを更新しなければならないからです。10ページ作っていたら10ページ、50ページなら50ページ分更新しなければなりませんので、１ページずつやっていたら・・・気が遠くなりそう・・・。
とまぁ、ここまでお話しすればお気づきとは思いますが、表示の度にページを作成するPHP版では、全ページ更新はいらないってことになりますね。テンプレートを入れ替えれば即反映です。

実は、PHP版で全ページ更新が出来ない理由がもう一つあります。それは、データベース用カスタマイズのベースとなるという目的があるからです。数千件や数万件の規模で全ページ一度に更新なんて、負荷が大きすぎてさせられませんからね～。

３，CGI版には一覧表作成（ボタン）がありますが、PHP版にはありません。
理由は２と同じですね。表示する際に作成するなら、あえて作成する操作は必要ありません。

結局のところどこが違うかというと、１につきるってことになりますかね。まぁ、PHPに「移植」したわけですから、理由があって違うところ以外は同じってことですね。

PHP版プロフィールメーカー3

PHPとPerlの違いについて考えてみた。
Perlは、プログラミング言語って感じ。PHPがそうじゃないという意味ではなくて、Perlはプログラムで処理した結果をhtmlとして返すという感じ。だから、最終結果を返すところまでは、ある意味webだとかどうとかいうことは一切関係ない。それに対してPHPは、htmlの中にスクリプト（プログラム）を埋め込むって感じ。だから、htmlしか書いてない（プログラム的処理を何もしていない）PHPだって存在しうる（意味はないけど）。もちろん、PHPだってPerlの様に書くことも出来るんで、あくまで基本的な設計思想で分けるとってお話。

とここまで考えると、CGI（Perl）版プロフィールメーカーの「ページを作成してhtmlとしてサーバに書き込む」という仕様は、およそPHPらしくないって思えるようになった。PHPなら、「ページそのものがPHP」として使うのが正当なんだろうね。これはCGIで言うと、毎回ページを作成して表示することに相当するするんだけど、まぁPHP自体がそもそもCGIより負荷が小さいんで、これはこれでいいのかなっと。

さて、そんなこんなで仕様の確定したPHP版プロフィールメーカーは、こちらです。解説は次回から～。

PHP版プロフィールメーカー2

ローカルで動いていたものが、サーバ上では正常に動いてくれません。
fopen(): SAFE MODE Restriction in effect・・・

とかいうエラーが出ます。何すか、SAFE MODEって？

fopen()のところで起きてるんで、ファイルの読み書きの際に起きていることはわかります。調べてみると、プロフィールページが作成されてません。パーミッションのせいかと思っていじってみたが変化無し。さらによく調べてみると・・・

/profPHP/（プロフィールメーカーのディレクトリ。FTPで作成）
　┣list.html（CGIが作成する一覧ページ。これは作成される）
　┣/AAA/（CGIが作成するディレクトリ。これは作成される）
　　　┣index.html（CGIが作成するプロフィールページ。これが作成されない）

なるほど・・・CGIが作成するディレクトリには書き込み出来ないってわけですか・・・うちのローカル環境では問題ないのに・・・調べてみると、SAFE MODEってのはインストール時の設定であって、スクリプト側でどうこう出来るものではないらしい（つまり、うちのサーバとローカルとでは設定が違う）。しかも、レンタルサーバでは、安全のためSAFE MODEにされていることが多いらしい。するって～と何かい？CGI版と同仕様じゃ環境依存してダメってこと？

ははは、どうすっぺか・・・（つづく）。