ユーザーが記録した分に基づいて機能するzendプロジェクトを作成しています。日付範囲に基づいてレポートを生成できる必要があります。私は誰かが私はその情報の格納を処理するための最良の方法を把握するのに役立つことを願っています。MySQLデータベースの日付に基づいてユーザーのデータを構造化する方法
私はusersテーブルを使用して、すべての重要なプロファイル情報を処理しています。私は分を追跡するためにこれを別のテーブルにリンクするのが最善のケースであると考えています...私はそれがどのようにレイアウトすべきかを考えていません。私は日付のデータベースの列を使用することを提案するいくつかのページを見てきましたが、それはすぐに扱いにくくなるようなものです。
1500人のユーザーと複数のユーザーが毎日投稿している現行のサイトでは、どのようにIDを調べるか分かりません。
助けがあれば助かります。 おかげで、私はあなたが探していると思うものに基づいて
一つのアプローチ、：
はuser_idのFK、START_TIME、およびEND_TIMEを含むUser_Sessionテーブルを作成します。ユーザーがセッションを開始したり終了したりするたびに、このテーブルに新しい行を書き込みます。ログイン時にこれらのUser_IDとStart_Timeを取得し、セッションが終了するかユーザーがログオフするとEnd_Timeを取得できます。
これで、[1500ユーザー] x [1日のセッション数]の履歴表が得られました。これは大きなものですが、想像もできないほどです。 （特に適切に索引付けされているかどうかを確認することができます。）SELECT USER_ID、SUM（End_Time - Start_Time）など、そのテーブルに対して問合せを実行して、必要な日付範囲と照合できます。
テーブルサイズを制御するには、これらの集計値（User_ID、MMYY、Num_Minutes）を格納し、ソーステーブルをいくつかの設定スケジュールで切り捨てることができます。ただし、計算されたフィールドを保存することは、正規化されたデータを手元に置くことには好ましくない場合があります。だから、ソーステーブルのサイズが大きな問題であると判断するまで、そのルートには行かないでください。
多くの方法のうちの1つであり、明快にするために単純すぎるものです。
それは理にかなっています。それはまた私が後で予定されている機能性の一部についても説明しているので、それもありがとう。 – Cpage
もしあなたがもう一度質問してもいいかもしれません...私はこのサイズのデータベースより若干新しいですが、あなたはどの時点でデータベースが「大きすぎる」と言っていますか？私はこれがすべてファイルサイズ、サーバーなどに依存することを知っています。あなたがいつ問題を引き起こしているかを知ることができる一般的なアイデアを探しています。 – Cpage
100,000以上の行は問題ありません。キーとなる考慮事項は、適切な設計されたテーブル（必要なキーと不要なデータを格納するだけです）と索引付け（照会するフィールドに対して適切な索引を選択することです）です。もちろん、サーバーの速度とファイル・サイズは重要ですが、 10年のうちに9回何を焼くか。 – LesterDove
ええと、ユーザーのログに記録されている分数を拡張できますか？彼らはこれを手動で行うのですか、それとも「サイトに費やす時間」ですか？ – Aatch
これは手動で入力します。教師が実際に学生がいつでも読んだ時間を入力するのは、実際のところです。 – Cpage