ってことくらいは知ってる。
MCDBAも持ってるし。
ただ、どの情報の格納にデータベースを使えばよいかの判断について、皆目不明瞭だった。
情報を格納するのなら、ファイルでいい。
#広義ではファイルシステムもデータベースだけど。
テキストファイルで良いのなら、その方が分かりやすい。
typeコマンドやメモ帳など、中身を見る手段はいくらでもある。
多量の情報を処理することも、一度プログラムを組んでしまえばどうということはない。
いくらISV試験を受けても、こういう実に基本的な事柄ってやつは、出てこないし、解決されない。
データベースというものがあって、どういうものかも分かる。
確かに情報を格納したり参照するといった処理をするのには便利な機能がいっぱいだ。
でも、今ここにある情報をデータベースに格納する意味はあるのかと。
今回のカウンタフィルタで、自ら初めてデータベースを利用したのではなかろうか。
#恐らく、今まで、こういう機会が無かったから、データベース苦手意識があったのかも知れない。
データベースを利用しようと思ったのには、多分、いくつかの理由がある。
#単にカウンタだけであれば、カウント数を保管するテキストファイルだけで済むからだ。
まだよくわかっていないかも知れないけれど。
まず、IISログファイルと同等かそれ以上の情報を格納したいと思ったことが一番大きい。
データベースは多量の情報を格納するのに適している。
ただし、IISログファイルはテキスト形式だが、多量の情報を格納するために日毎に切り替えたりできるので、多量の情報を格納するのにもあまり問題になることはない(はず)。
#問題になるほど多量の情報なら、量の大小はあるにせよ、データベース使う場合でも問題になる(はず)。
次に、格納した情報の閲覧が面倒だったというのがある。
IISログはフォルダに格納されているのだけれど、typeコマンドとfindコマンドを連結して、コマンドプロンプトで見ると、一応見れるけれど、各サイトを横断的に見たり、するのには不向き。
また、コマンドプロンプトでは表組みで表示することは困難。
SQL Serverなら表組み表示も得意だし、たとえ複数のテーブルに分かれていたとしても結合もできる。
単テーブルの閲覧だけなら、プログラムを組むことも不要だ。
#少しはSQL文の記述が必要な場合もあるのだが。
最後に、排他処理。
更新が重なる場合もあることを考慮すると、どうしても、ロックによる処理遅延なんかを気にする必要も出てくる。
SQL Serverならば、その辺はおまかせできる。
IISログもおまかせできるけど、IISのログ行数をカウントするのは、ファイルが複数だとちょっと面倒。
自分でカウント処理を実装するのもいいけれど、また排他処理を考えなきゃいけなくなる。
蛇足として、編集。
実は、今回のカウンタをつくるにあたって、いわゆるクローラーをカウント除外しようとして、フラグを1つ入れている。
これによって、集計数からクローラーを除外するわけだけど、未知のクローラーを新規に登録するのはプログラム更新でやってる(このあたり、web.configに入れたい)んだけど、既にログ化されたデータを変更するのにも、テキストファイルでは、検索→置換と手間が掛る。
データベースなら、UPDATE文で該当レコードを全件処理できる。
つまり、蓄えるだけじゃなくて、あるていど纏まった編集処理を必要とするならば、データベースへの格納は有意義だと言える。
あとは、自分のスキル確認って面もあったりするんだけど、それは置いて、データベースを使うメリットがあれば、使えばいいって程度のものと感じるようにはなった。
逆に、メリットが無い場合には使わなくていいと思う。
データベースを使うのは手段の1つであって、目的じゃない。
使えるスキルはあったほうがいいけれど、何が何でも使わなきゃダメってもんでもないなぁと。
その程度のお気軽感を持って、今後も使っていけば、何とかなりそうだと、俺的には1歩前進。
コメントしちゃいなよ