2012-03-14 9 views
2

は私がログインログアウトログを保持するためのテーブル構造は何ですか?

Field  Type 
login_id int(10)  NOT NULL 
platform varchar(50) NOT NULL 
browser  varchar(50) NOT NULL 
ipaddress varchar(50) NOT NULL 
last_login datetime NULL 
last_logout datetime NULL 

を次のようにloginlogのテーブルを持っている。しかし、この構造の上に、私は私がログイン時間を追加することができますが、そのハードログアウト時間のためにそれを更新することを混同しています。ログは頻繁になり、プライマリキーはすぐに最大値に達するので、私はプライマリキーを追加していません。何が最善の方法でしょうか?助けてください。

+2

"およびプライマリキーがすぐに最大値に達する " - これが問題であれば、大きな問題があります。 – Amber

+2

'INT'は' 2147483647'まで異なる値を格納できます。 1秒に1回ログインしていても、login_idが枯渇するまで68年が必要です。この問題が発生した場合は、単に 'BIGINT'に更新するか、ログをクリアしてください。 'BIGINT'は' 9223372036854775807'までサポートしています。毎秒100万人のユーザがログインしていても、あなたの新しい制限に達するまでには300,000年も掛かりません。 – Basti

+1

'session_id'をフィールドとして追加してログアウトするときに、対応するセッションIDでログアウトを更新してください。これにより、異なるブラウザ/マシン上の複数の同時ログインも解決されます。 –

答えて

0

最後にログインして最後にログアウトする情報が必要な場合は.... user_idをプライマリキーにして、新しい情報を追加するだけですあなたの機能を向上させる1つのカウントフィールド...人がログインしているカウント数を取得する...

そして、それぞれのログインデータが必要な場合は...シリアル化のコンセプトを参照してください。ヘルプ...配列の数をキーとして、最後のログイン、ログアウト、配列の値としてブラウザ...データベースをシリアル化してデータベースに保存する...

+0

私は毎日のログインエントリをログに記録する必要があります –

2

なぜなら、2つの列。
に対応するlogin_idとログアウト時刻を参照してください。

last_loginとlast_logoutはわかりませんが、ロジックが必要な場合があります。 IMOでは、カラムを持つことを避けるべきです。カラムにはNULLを含めることができます。

編集:アドオンとして、なぜあなたはそんなに多くのデータを蓄積するのだろうかと思います。ユーザーのブラウザ、プラットフォームを分析するためのの場合は、Googleアナリティクスを使用できます。そして、各ユーザーのためにlast_loginとlast_logoutを保持することができます。この場合も、ビジネスロジックで必要となる場合があります。

0

私の提案は、一度主キーが最大値に達するのを避けるために一度ログインすると、各ユーザーのエントリを更新することです。

+0

投稿の下のbastiのコメントを参照してください。主キーの最大値に達することは現実的な問題ではなく、その周りをデザインしたい場合は、より大きなint型を指定するだけです。 – octern

2

ログインとログアウトの両方を1行にすると、トラブルシューティングが必要になります。なぜなら、すべてのログインに対応するログアウトがあると想定しているからです。時には、公共のコンピュータにログインしてログアウトしないこともあります。匿名のウィンドウを開き、ログインすることもあります。

代わりに、私はちょうどタイプにそれを削減します:

  • プラットフォーム
  • ブラウザ
  • のip_address
  • タイプ(ログイン/ログアウト)
  • をLOGIN_ID
関連する問題