ども、戸部です。

On Mon, 27 Dec 1999 12:25:54 +0900
"Isamu Narimatsu" <isamu@xxxxxxxxxx> wrote:

>成松です。
>
>>あとはテーブル自体の構成を変えて
>>blog(記録テーブル)
>
(省略)
>
>こういったアクセスログを記録、解析する場合に一つにのテーブルに記録する場合と
>複数のテーブルに記憶する場合と二通り考えられます。
>
>どちらの方法を使い設計するで、運用方法も変わってくると思います。

(省略)

>そこで、みなさんは一般的には、MySQLを使用して、テーブル作成を1つにしたり、複
>数にしたりする場合はどのような考え方で選択されておられるのか、ご意見を頂けた
>らと思います。
>

これはどのようなアプリケーションで使用されるかということと関連して
くるかと思います。

たとえばレコードを分割する場合は、あまり良いたとえではないけど、
人事データベースにおける社員の住所と社員の評価というように
お互いが完全に独立したデータであり使用される場面が異なるような場合は
２つのテーブルに分けたほうがいいかと思います。

今回の表示とクリックの場合、２つの別々のデータとしてみることもできますが
１つのアクションの記録の属性として捕らえることもできます。
つまりユーザが行ったアクションとして表示だったのかクリックだったのかを
属性値として記録するという考えです。

たとえば道路の交通量調査を行うときに、乗用車の通ったLogとバスの通った
Logを分けて考えるのではなく、交差点を通過したという記録で種別はなに
というような形です。

もっとも先にMailで上げた表示とクリックのカラムを分けて１つのテーブルに
する方法は正規化というのはまったく無視して表示の簡単さを取った形です。
正規化を考えた場合、

blog(記録テーブル)
+----------+------------------+------+-----+---------+----------------+
| Field    | Type             | Null | Key | Default | Extra          |
+----------+------------------+------+-----+---------+----------------+
| id       | int(10) unsigned |      | PRI | 0       | auto_increment |
| comid    | int(11)          | YES  |     | NULL    |                |
| action   | int              | YES  |     | NULL    |                |
+----------+------------------+------+-----+---------+----------------+

というテーブルを作り、action が 0 なら表示、1 ならClickというように決めて

SELECT id, action, count(*)
  FROM blog
  GROUP BY id, action;

としたほうが一般的でしたね。
この場合の利点として現在はActionが２種類しかないけど将来的にその他の
Actionを加えた場合にコードの変更が別テーブルにするより少ないかな。

たとえば先の交通量調査の例では、今まで自動車とバスの交通量を調べて
いたところに新たにバイクの交通量も調べるようになった場合に、
自動車通過Log,バス通過Logというわけ方をしているとバイク通過Logと
いう新しいテーブルが必要となるけど、属性の値で種別を分けた場合は、
テーブル自体の変更はせずにデータを登録するところのロジックを
若干変更して表示の仕方を変える程度で済むかと思います。


実際テーブルの設計というのはどれが正解というのはないかと思います。
自分の仕事での経験でも完全に正規化を行った場合はテーブルの結合が
発生しすぎて使い物にならないのでわざと正規化を崩したり、
精度よりもスピードをとって日時バッチとかでサマリしたデータを持つ
テーブルを使ったりと結構教科書どおりではない設計も多いです。

ですからいろいろと試行錯誤しているうちにKnowHowが身についてくると
思います。
# 最初はSQLの本を読むなどの正しい知識を身につけたほうがいいですけど(^^;)

では。

--------
  戸部　貴紀 <takanori@xxxxxxxxxx>