ミヤタ 様,

返信が遅くなり申し訳ありません。増田です。

2010年6月2日12:35 Miyata Masaki <catlover@xxxxxxxxxx>:

> いきなりざっくりと私なりの結論を申し上げますと、「分からない」となりますが、
> 仮の状況として設定されたユーザ10名の例で言えば、「大差ないでしょう」となります。
> ユーザ10名程度で業務系の処理を想定されていると思いますが、そうであれば
> パフォーマンス（※）は大した問題にはならないと思います。
>
> ※パフォーマンスと一言で言われているのでそのまま使っていますが、
> 　パフォーマンスといっても、さまざまな要素があります。
>
話を分かりやすくしようと思い、ユーザ10名等たとえをあげたのですが、
あくまでユーザは万単位を想定していて、
一か月単位で参加できるユーザが10名という意味でした。

というか、一か月というのも分かりづらく、これも本当に申し訳ないのですが、

本来は、一試合に参加できる人数が10~20名程度で、
一試合のなかで、5~10日ほど日にちが立つというものを作っております。

最初からこちらで説明すればよかったですよね。申し訳ないです。


> ですが、テーブルの正規化という意味ではtable2の方が望ましく柔軟性も高いため、
> 問題なければtable2にしておく方が良いと思います。
>
> ただ、処理が多少複雑になるとは思いますので、table1でも柔軟性やパフォーマンスに
> などに問題がないと分かっている場合には、別にtable1でも構いません。
> table1でパフォーマンス上不利になるのは、カラム数が増えるため、同時更新による
> ロックなどで更新性能などが落ちることなどです。
>
一試合のうちに、5~10日ほどありますが、その日替わりで同時更新が入る程度で、
ユーザが何度もUPDATEできるようなテーブルではないので、今のところ性能的には問題ないように感じます。
（カラム数が多いと同時更新に気をつけたほうがよいのですね。勉強になります。）


>> ただし、アクションを2つ行えるのは3名しかいないため、残り7名にとっては無駄なフィールドがあって、
>> あまり効率よくない感じがします。
>
> 使用しないカラムはNULLにしておけば問題ないと思います。
>
NULLでも特に問題ないんですね。NULLってなんかあると悪いような気もしていたのですが、
そうでもないんですかね。


>> ただし、フィールドに無駄はありませんし、WHERE句を使えばデータは取ってこれるので、
>> 1レコードとしては見にくいですが、データを素早く取ってこれることが大事なので、
>> こちらのほうがよいのかなと思っています。
>
> 厳密に言えば、データを素早く取ってくるという意味では、1行だけ取得すれば良いため、
> table1の方が優れています。
>
>
>> 一ヶ月目で、130ぐらいレコード数が増えます。
>>
>> これを1000ヶ月とか10000ヶ月になった場合、膨大なレコード数になり、パフォーマンスが落ちないか心配な面があります。
>
> それ位の行数であれば、全く問題ないと思います。
> 想定されているコンピューターに相応のデータを入れて試される事をオススメ致します。
> MySQLやApacheのパフォーマンスに関する設定項目も多数ありますから、それらの設定でも
> パフォーマンスは大きく変わりますし、コンピューターのCPUやメモリなどによっても、
> パフォーマンスは大きく変わります。
>
パフォーマンスに関してはおっしゃる通りですね。
my.confの設定でも変わってきますし、CPUやメモリによっても変わってくるというのは分かりますが、
同環境で、できるだけCPUに負荷をかけず、時間を短縮できるという我儘な願いをもっております。
ただ、I/O負荷になって、サーバ止まっても困るので、より綺麗なテーブル設計ということでもよいのかもしれません。

一か月のたとえが悪く申し訳ないです。
正確には試合単位なので、10000試合とか、もしかしたら50000試合ぐらいにもなるかもしれませんが、
いずれにしてもそれぐらいであればそこまで気にする行数ではないのですね。

万単位の行数で考えることなど今までなかったため、今回心配しておりました。



>> table1だと、
>>
>> key | month | user_id | 1day_action1 | 2day_action1 .... 10day_action1
>> | 1day_action2 | .... 10day_action2
>>                  target
>> として、アクションフィールドのデータにその行為のターゲットを入れればデータは取れるので、
>
> すみません。上記の意味がよく分かりませんでした。
>
1day_action1 | 2day_action2 |
target_id        | target_id

ということでした。分かりづらく申し訳ありません。



増田
-- 
mailto:masuken@xxxxxxxxxx