3D動画のグランブルー3Dのブログ
■3DCG動画のグランブルー3D


【 MySQL・データベースをPHP・プログラミング言語で操作する方法 】

先回は、DB定義とデータハンドリングについて述べました。
今回は、PHPでMySQL・DBをハンドリングする時の苦労、また優れた所をかいつまんでお話しいたします。

まず、PHPによるDBハンドリングの知識として何が必要か?

DB設計・定義・生成の知識と技術、およびサーバー設定の知識が必要です。
但し、こちらは利用者の立場として必要最低限の初期設定パラメーターに係る知識で済みます。
DBについては、大型コンピュータ向けのORACLEも、
今回のような極めて小規模なDBも、
基本的な構造や考え方は変わらないので、
それなりの知識と経験を持った人ならば、MySQLを使ってDBを創生することは難しくない。
もっとも、このあたりのことはシステム・エンジニアの領域であるけれども。
まあ、総合的なシステム開発の知識が必要になります。


【 PHPのCGIより優れているところ 】

PHPの良さは、使ってみてCGI(parl)などよりも理路整然としてわかりやすい。
関数を如何にうまく使いこなすかで、たいがいのロジックは組める。
関数は膨大にありハンドブック片手にプログラミングをするのですが、
頻繁に使うものは自ずと限られてきますので、
ハンドブックは頻度の低いロジックを適用するときにのみ探索に使います。

その意味で、保守する場合もCGIコードよりもPHPコードの場合の方が簡潔に仕上がっているので見やすく、追いやすいです。
また、
CGI(parl)の場合、HTML記述部分をparl仕様に書き直す必要があるが、
PHPの場合、HTMLにPHPコードを挿入するということもできるので、
Webサイト・Webアプリ構築の立場からすると制作し易いというメリットがあります。

実際に使ってみて感じるPHPの良さは、
ユーザーインターフェース(UI)となるWebサイト・デザインのHTML構文をそのまま生かしながら、
プログラムロジックが必要になるところは、
PHPコードを<?php ・・・?> で挿入すれば済むという優れた所である。
これは、Webデザイナー兼プログラマーにとっては、
とても、ありがたいことで、
デザインも損なわずにロジックが組み込めるということで制作する際のストレスが貯まらない。
CGIなどparlで、こだわりのデザインのあるサイトとロジックをうまく両立させるには、相当なストレスが発生する。
その意味で、PHPが普及してくれていることは、とても制作する立場からすると大いに助かるのである。


【 PHPでMySQL操作のSQL発行関数を使う 】

さらに、
PHPはDBハンドリングをするMySQLとも相性がよく、
小規模DBだけでなく、ORACLEなどもサポートしているという優れものです。
実際、PHPでMySQLを使ってみて、SQL発行の関数を発行すればよいので、至極、分かり易いです。
但し、
条件を組み合わせた検索や、追加、修正、削除のオペレーションになると結構、不明なデバックエラーが発生して、その原因究明に四苦八苦することもしばしばです。
デバック・エラーメッセージがもっと親切に表示してくれればと思うところが多々ありますね。
その意味で、デバックテストにはDBへ正しいSQL構文を発行しているのか?
机上デバックを十分にすることが、結構、早道だったりします。
プログラミング・コーディングの後に、いきなり、テストデータを流すのは、ご法度でしょう。
まあ、そのような軽率なやり方はプログラマー初心者のやることで、熟練者は、目を皿のようにして机上デバックを重視します。
ちなみに、
机上デバックとは、コードをロジックどおりにコード化しているか? チェックしながら、頭の中でプログラムの動きをシミュレーション(模擬稼働)することです。
PHPプログラミング言語文法とMySQLのSQL文法を熟知していることが必要です。
その後で、確認程度にテストデータを幾度か流して、ロジックの正確さをチェックするというのが正道です。

次回のお話をお楽しみに!


■3DCG動画のグランブルー3D


--------------------------------------------------------------------


3D動画のグランブルー3Dのブログ
■3DCG動画のグランブルー3D


【 MySQL リレーショナルデータベースの定義とデータ・ハンドリングについて 】

先回は、データベースとユーザーインターフェースの優先度はどちら? を述べました。
今回は、もっと具体的にデータベース構築の手順をお話しいたします。

データベース(DB)設計には、それなりのコツが要ります。
まず、観点として業務的な必要項目を拾い出すこと。
それから、システムコントロールのための項目を拾い出すこと。
その2点です。

【 業務データの抽出と洗練 】

業務的な項目は、アプリの仕様がある程度見えてくれば、自ずとDBに管理すべきデータ項目が見えてきます。
業務上、保存すべきデータは何か?
一時的に保存するものなのか?
継続的、累積的に保管すべき重要な項目なのか?
また、
登録と廃棄タイミングは?
計算ロジック上で出現するデータなのか?
それとも
ユーザーインターフェース(UI)で入力するものなのか?
などなど、実に多くの側面からデータの特性や属性(英数字か、日本語か、可変長、固定長かなど)を分析、整理していく必要がある。


【 コントロールデータの抽出と整理 】

それに合わせて、データのハンドリングを考えたときに、
タイミング合わせとか、フラグとか色々なコントロール項目が浮かんできますので、
それも拾い上げていきますが、初期の段階ですべてを完璧に拾い上げることは難しいです。
よって、開発途中で追加するケースが続発するので、DBのテーブル定義、フィールド定義をする際に、拡張できる余裕を考慮して設計、定義することが重要です。
このあたりのテクニックは経験がものを言いますが、
初めての人も、そのようなことは考慮しつつ設計されることをお勧めします。


【 データベース定義とツール 】

データベース定義は、MySQLのコマンドラインからDB創生、テーブル創生、フィールド創生のSQLを発行して実行もできるが、量が多いとなかなか大変である。
実際のPHPプログラムではPHPのMySQLサポートの関数を使って、コマンドラインと同じことができるが、一々そのためのプログラムを作るのも大変である。
しかし、
PHPとMySQLの組み合わせでサービス提供しているレンタルサーバーでは、
phpMyAdminというとても便利なDBハンドリングのツールを標準提供している。
これはPHPベースで作られており、一般的に普及しているもので、ほとんどのDBハンドリングの処理には有用である。
DB定義、テーブル定義、フィールド定義まで全て可能で、データもダイレクトに入力が可能(SQLを自動的に発行して)である。
また、
ローカル環境向けにも、無償でWebからダウンロードし、インストール簡便にできるので、重宝している。
まずは、これがないととても不便であり、テストでDBの更新内容の適否をチェックするには必須のツールです。
システム環境の設定と合わせて是非とも整備したいツールである。
なお、
詳しいことを知りたい方は、その筋の市販ま専門書でご勉強ください。


次回のお話をお楽しみに!


■3DCG動画のグランブルー3D


--------------------------------------------------------------------


3D動画のグランブルー3Dのブログ
■3DCG動画のグランブルー3D


【 データベースとユーザーインターフェースの優先度はどちら? 】

今回は、データベースを中心に実際、開発していく時に、フッ!と疑問に思ったりするところをお話ししてみたいと思います。
これは、当方の苦労と経験のたまもので築き上げた知見なので、必ずしも教科書どおりではないし、ご参考までとご理解ください。

初めて、データベースの定義、構築をする人にとっては、
どこをどのように、途っかかっていけばよいのか? 見当がつかない。

今回のお話では
データベースはWebアプリ構築の小規模向けということでMySQLを採用した。
MySQLはメジャーなレンタルサーバーでは昨今は、サービスメニューとして一般化してきており、ローカルサーバーのApacheの配下で、かつ、PHPプログラミング言語とも相性がとても良い。
MySQLは大規模DB・ORACLEと同じくリレーショナル・データベース(RDBMS)で、小規模向けながらも、やっていることは大型並の優れものです。
さて、
リレーショナル(関係)・データベースとはなんぞや?
という疑問に答えると、
正確にいえば、リレーショナル・データベース管理システムのことで、
ザクッと言ってしまえば
「EXCELのような表(テーブル)形式にデータを格納するDB」
ということです。
EXCELについては、皆さんがおなじみの表計算ソフトですから違和感はないと思います。
実を言うと、EXCELとリレーショナル・データベースはCSV形式のファイルを媒介としてやり取りができます。
よって、DBに登録のデータをEXCELに落とし込んだり、逆にDBに登録するソースデータの作成としてもEXCELが使えたり、ととても相性が良いです。

さて、本題に入りますが、
システム設計をするとき、
ついつい分かりやすい画面の設計から入りがちですが、それは、間違いです。
まずは、
適用業務としてのユーザーが実務で扱っているデータ項目を業務手順フローチャートを分析、描画していると同時に整理していくのが先決です。
データの項目、属性、特性、生成消滅更新のタイミング、重要度など根気よく拾い出して解析していくことが重要であり、正道です。
よって、
データ設計の初動はリレーショナル(関係)データベースであることを念頭に置きながらデータ正規化という洗練をします。
データ正規化とは、鉱脈から掘り出した金鉱石を洗練して純金を抽出するようなものです。
純度100%にするのが理想ですが、なかなか難しいものです。
詳しい事は、その筋の専門書をお買い求めいただいて勉強してください。

しかし、
教科書的な正論の手順では、そうなのだけれども、実際、経験の浅い人が「データ正規化」に取り組んでも、そう簡単にはいきません。
そこで、
もっと実践的なのが、やはり、ついついやってしまう画面設計をとりあえずやることです。
すると扱うデータの全貌が何となく見えてきますので、それを表形式に洗い出しを行って整理します。
但し、見栄えの良いレイアウトデザイン・・・云々は、後での話です。本末転倒しないようにご注意ください。


さて、疑問が沸いたと思います。
ユーザーインターフェース(UI)の設計が先なのか?
データベース(DB)の設計が先なのか?
と疑問に思われるかもしれないが、
これも鶏が先か、卵が先か?
と同じ議論で、
実際は両方を並行してやっていく。

すなわち、いきなりプログラムベースの仕様書を作ろうとしても、それは重箱の隅っこをいきなり、突っつくようなもので、あまり賢いやり方ではない。

【森】を俯瞰して、全体のあたりをつけて、機能ブロックの【林】にまで目線を下げて、さらに【木】のレベルで初めてディティール(細かい事)へのこだわりを行う。

ユーザーインターフェース(UI)のデザイン的なものは、設計の最後の仕上げとしても、DBとの間でやり取りするデータ項目がシステム外部から入ってくるものなのか?
を設計するという極めて基本的なことは、DB設計と並行して行うことになる。

データを中心としてロジックはそれに従属するものと考えるのが、現在のリレーショナル・データベース・システム構築の主流である。
データ定義が完成してからプログラムコーディングを行うのが順当です。
何となく、データベースの定義にまでたどり着けそうな感じがしましたでしょうか?
次は、もっと具体的にお話しします。


次回のお話をお楽しみに!


■3DCG動画のグランブルー3D


--------------------------------------------------------------------