データベース - 我流データベース設計 - カウンタ

1.　概要

2.　構成

3.　テーブル

1.　概要

　わたしが、管理しているサイトは、表示しているか、していないかにかかわらず、カウンタを持っています。
　１日内で、ユニークなアクセス元がアクセスするごとに、カウントアップ。
　また、アクセスにかかわるログ的な情報を、１アクセスごとに１行分、テキストファイルへ出力しています。
　日替わりの時点で、１日分をまとめて、管理者用のメールに送信。
　カウンタ値は、保持しつつ、ログファイルは、リセットして、１日分は最初から出力しなおします。

　しかし、これは、インターネット創世記を過ぎたあたりに、どこかから拾ってきたものに手をいれたもので。
　テキストファイルにアクセスする方式が、いささかほころんでいて。
　排他がうまくいっていないのか、カウンタファイルの中身が何もなくなったりして、下手をすると、サイトの表示がこけはじめたりするのだ。
　ファイルアクセスとテーブルアクセス、どちらがリソースを食わないのかとか、アクセススピードはどれくらいとか、問題はありそうな気がしますが。
　もし、こけないようになるならば、テーブルアクセス方式にしたいなぁ・・・と思いまして。
　やってみるべか。

2.　構成

　データベースとテーブルの構成、少し悩みます。
　サイトは、それぞれ自分用のデータベースを持っています。
　このデータベースそれぞれに、カウンタ用のテーブルを持つべきか・・・。
　それとも、サイトを横断するデータベースを新規につくって、サイト用のテーブルをつくるべきか・・・。

　一長一短ありますが、サイトの増減を考えると。
　サイトそれぞれのデータベースに、同じ構成のカウンタテーブルを持つ方が、わたしには管理しやすいように思えたので。
　当初、サイトそれぞれのデータベースに、同じ構成のテーブルを持つ方式でやっておりましたが・・・もとい。
　手詰まりになりました。
　サイトを横断するデータベースを新規につくることとします。

3.　テーブル

　まず、サイトを横断するカウンタテーブル。

　カラム名が、どうしても予約語と重なっちゃうので、変になっちゃいますね。
　サーバに、「PostgreSQL」を想定しているので、アクセス日は、「date」型になるのだ。
　カウンタ値が「オーバフローしたらどうするの？」。
　いやいや、わたしの生きている間に、オーバフローすることはないな。
　まぁ、心配な向きは、周回カラムでも設けていれば、2の63乗×2の63乗くらいになるので、人類の週末くらいまではもつでしょう。

　もうひとつは、アクセスログ用のテーブル。
　これは、テーブル名がサイト名と一致させるようにして、複数の同じ構成のテーブルを作成します。