---

掲示板を作ろう！ということで、設計だ！！！



と、思っていたんですが、こういうコラムを見つけましてね。



テーブル設計は実装の後に！- @IT


このタイトルを見て、僕は「うっわマジかよ･･････」とも思いましたし「どうせ内容のない釣りだろ」とも思いました。
が、読んでみると意外とそうでもなくて、確かにそういう考え方もアリだなと思いました。


一般的に、実装する前にきちんと設計しといた方が良い場合がほとんどです。
設計時点できちんと整っていれば、後はそれに沿ってコーディングするだけです。設計に伴いデータも整理されているので、散らからずに扱いやすいです。当然ですね。
設計をするだけでコード量が半減したりしますし、#32とかでお見せしている通り、データが見やすくなり管理も容易になります。後から拡張もしやすくなります。いいこと尽くしです。


が、特に一人で設計から実装までやってるとままあることなのですがその場で思いついたシステムを導入したくなるって時もあったりするんですよね。
設計時点では考えもしなかったアイデアが、コーディング中にふっと出てきてしまう。そんなことは割とあると思うんですよね。ただ、設計は出来上がってしまっている。必要なデータが扱いにくい形になってしまっている。でも、アイデアは素晴らしいので無理やりにでも実装しよう、と。
こうしてつぎはぎのシステムが作られていくわけですね。


あと、さらに言うと設計って思ったより難しいんですよ。
皆さんもなんかシステム考えてみてください。それを簡単に図示してみてください。すべての画面をですよ。それでもって、必要なデータとか考えてみてください。結構な労力がかかります。
もちろん、企業でやるような設計よりかはだいぶ簡素化してます。ほんとはクラス図とかアクティビティ図とか書いたりしますが、僕には意味がわかりません。（笑）
ただ、確かなことは落書きレベルの設計でもかなりめんどくさいということです。


その理由は簡単です。目に見えないものは想像しにくいんですね。



ということで、アジャイル開発の手法を取り入れたいというわけですね。
アジャイル開発ってのは簡単にいうととにかく目で見えるものを作っていく開発手法って思っておけばいいかと思います。短いループを何度も繰り返して、リファインしていくことで完成品に近づけていくわけですね。
比較的小規模なシステムに向いた開発手法です。当然、大規模なシステムでそんないい加減なことするとよろしくないですが、規模が小さいとリカバリが効くので、とりあえず形だけ作って･･････ってのができるわけです。
で、このアジャイルの一番大きな利点は成果物が目に見えるから分かりやすいということです。



具体的な発想は先ほどに挙げたコラムで述べられているので割愛させていただくとして、ここで僕が学習しなければならないのはストアドプロシージャなるものですかね。現時点では一体何の話かよくわからないですね。
データベース設計を後回しにする、というところで何が一番問題になるのかっていうとテストデータを自分で作らなくてはいけないというところなんですね。だってデータベース自体がないんだもん。
このテストデータを用いて、とりあえずGUIだけ実装し、最後にデータベースの設計を考える･･････という流れにしたい、というのがこのコラムの結論です。

まずは設計から慣れた方が良いのでしょうし、多少の設計はしてから制作にとりかかるつもりですが、こういった新しい手法も取り入れてみることで開発もしやすくなるんじゃないかと。



ということでストアドプロシージャの話を今回したいと思います。


とりあえずストアドプロシージャとは何なのかというのをwikipediaで調べてみましょう。

ストアドプロシージャ (stored procedure) とは、データベースに対する一連の処理をまとめた手続きにして、リレーショナルデータベース管理システムに保存（永続化）したもの。永続格納モジュール（Persistent Storage Module）とも呼ばれる。ストアドプロシージャは実際にはデータベースのデータ辞書に格納されている。


一体何の話をしているのかさっぱり分かりません。（）

ただ少なくともこれ、ちょっと違う話をしている気がしますね。
英単語を見るとよく分かるのですが、要するにデータベースに対する命令をデータベースに入れておくってことですね。サブルーチンみたいなものですね。

ですが、このストアドプロシージャのアクセス先をダミーデータにすると、設計終了後にストアドプロシージャの該当部分を書き換えるだけでいい感じになりそうですね。
ロジックはなるべく分離させた方がいいと思いますからね。このストアドプロシージャもできることなら有効活用できたらいいかな。



ちょっとこのページだけだと方針が定まらないというか、具体的なことがわからないので他のページも見てみます。



オブジェクト指向言語ならNoSQLで、RDBMSを使うならサービス指向アーキテクチャで - SQLer 生島勘富 の日記



まぁ結局のところ具体的にはよくわからなかったので、ビジョンだけ目指して開発を進めたいなと思います。




上の記事から引用させていただきましたが、具体的にはこのビジョンでいきます。


「なんだ当たり前のことじゃないか」って思われるかもしれません。まぁ事実当たり前のことだとは思います。
が、これを意識した構造にできるってのが意外と難しいんじゃないかなと思うのです。



うーん、なんか方向性が違うよーな。





うーん。





最終的にやりたいことはGUIとロジックの分離です。


でまぁ、いろいろ調べたんですがMySQLではビューを戻り値とするストアドプロシージャが使えないっぽいので、ストアドプロシージャを使うのはやめます。
代替案としてデータベースを取り扱う関数をひとまとめにすることで、後々のメンテナンスをラクにできないかと考えます。



ということで次回は軽く設計をして、コーディングに入っていこうかと思います。