私はユーザーが社会的に交流できるオンラインシステムに取り組んでいます。もちろん、実際にオンラインであるユーザーを識別できることが重要になります。HTTPがステートレスであることと、セッションの使用について知っているので、ユーザーの最後のアクティブ時間を任意の有効期限と比較することによってこれを実現する必要があります。
私の最終的な質問はこれに帰着します：既存のメンバーテーブル（、、、など）にいくつかのフィールドを追加する必要がlast_active_timeありis_user_onlineますhide_online_statusか、それともこの情報を別のテーブルに保持するのが最善でしょうか？私の最初の考えは、単純化のために既存のテーブルを使用することです。複雑さのレベルは別として、一方と他方の長所/短所は何ですか？
新しいテーブルを作成します。
まず、哲学的な理由があります。それは、1つのオブジェクト（読み取り：テーブル）が1つの目的を持つ必要があるということです。これはデータベースの論理設計ではかなり曖昧になりますが、それでもそれは良い原則です。
ただし、実際の理由は物理的な設計にあります。まず、任意の時点でログオンするユーザーの数は、ユーザーの総数よりはるかに少ないと想定できるため、ストレージ要件は低くなります。また、ストレージ要件が低くなると、読み取りと更新のブロックが少なくなるため、データベースの負荷が直接軽減されます。
さらに、このデータをメインテーブルに配置すると、これらのブロックははるかに広いスペースに分散され、データを変更すると、ブロックの内容が継続的に拡大および縮小されます。
そして最後に、たとえば、現在オンラインになっているユーザーを確認するために、おそらくいくつかのインデックスが必要になります。そして、これらのインデックスは、（1）さらに多くのスペースを占有し、（2）ディスクに物理的に書き込む必要のあるさらに分散したダーティブロックを作成し、（3）更新の競合ポイントを導入します。
これは別のテーブルで管理します。100万人のユーザーがいて、誰がオンラインであるかを知りたい場合は、そのテーブルを何度もスキャンしてその情報を見つけたくはありません。「オンライン」テーブルは比較的小さく、過去5分ほどで入っていないものを定期的にスキャンし、オンラインテーブルから削除して、メンバーテーブルで必要なものを更新するジョブを実行できます。 「last_seen」の場合
それはあなたが何人のユーザーを期待しているかによると思います。ユーザーが数千人しかない場合は、ユーザーテーブルでオンラインステータスをユーザーの属性にします。それ以上になる場合は、online_usersテーブルが必要になり、メインユーザーテーブルへの外部キーを使用してその情報を保持します。（上記のポスターで言及されている）メリットを享受するには、数時間ごとにタスクを実行して、online_usersテーブルから非アクティブなユーザーを削除する必要があります。