PHP システムのお知らせ - 全員に通知を送信します
私はよくこのような経験をします。つまり、システムにログインするとシステム メッセージ プロンプトが表示され、このメッセージは全員に向けられたものですが、プログラムはこのメッセージを見た人と見ていない人をどのように区別するのでしょうか? (見ていない人にはページの上部にプロンプトが表示され、見た人には自動的に消えてしまうためです。) この効果は PHP を使用してどのように実現され、データ構造はどのように設計されているのでしょうか。
ディスカッションへの返信 (解決策)
まず、テーブルに既読か未読のフィールドが必要です
まず、メッセージ リストが必要です。テーブルに既読か未読のフィールドを追加するだけです。
100,000 人のユーザーがいて、見た人もいない人もいる場合、このフィールドはどのようにマークされるべきでしょうか?このメッセージの送信者と送信先もテーブルに記録する必要があります。これにより、各ユーザーのユーザー ID に基づいて個別のメッセージを読むことができます
テーブル構造
table1: message
msg_id msg_content public_time
table2:read
msg_id user_id read_time
システムメッセージを公開する メッセージにレコードを挿入するだけです
例:
123 "午後の休憩" 1414468731
見た人 読み取りテーブルにレコードを挿入します
123 5145 4468745
未読メッセージがあるかどうかを確認します
select * from message where msg_id not in (select msg_id from read where user_id = 5145)
SQL の効率が気になる場合は、次のコマンドを使用できます
select * fromメッセージが残ったメッセージ 結合 (select* from read where user_id = 5145)temp on message.msg_id = temp .msg_id ここで、temp.user_id は null です。
table2:read
msg_id user_id read_time
例:
123 "午後の休憩" 1414468731
読んだ人は読み取りテーブルにレコードを挿入します
123 51 45 1414468745
未読メッセージがあるかどうかを確認します
select * from message where msg_id not in (select msg_id from read where user_id = 5145)
SQL 効率が気になる場合は、次のコマンドを使用できます
select * from message where message left join (select* from read where user_id = 5145)temp on message.msg_id = temp.msg_id where temp.user_id is null
この方法も検討しましたが、もしあれば。システム メッセージが多すぎる場合、ユーザーの数が多いため、データベース操作の量が非常に多くなります。ユーザーが 100,000 人いる場合、1 つのシステム メッセージに対して 100,000 のレコードが存在します。
このメッセージの送信者と送信先もテーブルに記録する必要があります。これにより、各ユーザーのユーザー ID に基づいて個人的なメッセージを読むことができます
これは全員に向けられたものなので、このプッシュ モードではありません適当
テーブル構造
table1:message
msg_id msg_content public_time
table2:read
msg_id user_id read_time
システムメッセージを公開する メッセージを挿入する 記録するだけ
たとえば:
123 「午後の休憩」 1414468731
読んだ人は、readテーブルにレコードを挿入します
123 5145 1414468745
未読の情報があるかどうかを判断します
select * from message where msg_id not in (select msg_id from read where user_id = 5145)
SQL の効率性を考慮して、次のコマンドを使用できます。
select * from message where message left join (select* from read where user_id = 5145) temp on message.msg_id = temp .msg_id where temp.user_id is null;詳しいご回答ありがとうございます。私もこの方法を検討しましたが、システムメッセージが多すぎてユーザー数が多い場合、データベースの操作量が非常に多くなります。ユーザーが10万人いる場合、10万人になります。 1 つのシステム メッセージを記録するもっと簡単な方法はありませんか?
10W のユーザーは、ユーザーが各メッセージを送信するかどうかをマークするために 15K のメモリが必要です
1. メッセージを読み取ります setbit msg_123 5415 1
2. getbit msg_123 5415 を読み取るかどうかを決定します
メッセージ テーブルにコンテンツとユーザー ID が含まれている場合、userid=0 はメッセージがグローバルであることを意味します ユーザー テーブルに、1,20,123 のように、表示されたメッセージ ID を記録するフィールドを追加できます
の後に追加します。メッセージ ID を見たことがあります
メッセージが比較的頻繁に送信される場合は、別のメッセージ閲覧記録テーブルを維持することを検討できます。フィールドは uid と msgid の 2 つだけで、どのレコードが閲覧されたかを記録するテーブルを作成します。見たことがありますか? ? ?
見つからない場合は、彼に表示されます
テーブル構造
table1:message
msg_id msg_content public_time
table2:read
msg_id user_id Read_time
システムメッセージを公開する レコードを挿入するメッセージは可能です
例:
123 "午後の休憩" 1414468731
読んだ人は読み取りテーブルにレコードを挿入します
123 5145 1414468745
未読の情報があるかどうかを確認します
select * from message ここでmsg_id not in (select msg_id from read where user_id = 5145)
SQL 効率が気になる場合は、次のコマンドを使用できます
select * from message where message left join (select* from read where user_id = 5145) temp on message.msg_id = temp .msg_id where temp.user_id is null;
詳しいご回答ありがとうございます この方法も検討しましたが、システムメッセージが多すぎてユーザー数が多いとデータベースの操作量が増えてしまいます。ユーザーが 100,000 人いる場合、1 つのシステム メッセージには 100,000 件のレコードが含まれます。
笑 それから、redis の使用を検討してください
1. メッセージを読み取ります setbit msg_123 5415 1
2. getbit msg_123 5415 を読み取るかどうかを決定します
ありがとうまたまたお世話になります!
メッセージ テーブルにはコンテンツとユーザー ID が含まれます。 userid=0 の場合、メッセージがグローバルであることを意味します
ユーザー テーブルに、1,20,123 などのカンマで区切って、表示されたメッセージ ID を記録するフィールドを追加できます。メッセージ ID を確認したら追加します
メッセージが比較的頻繁に送信される場合は、uid と msgid の 2 つのフィールドのみが表示されます
はい!現時点では、これがより便利な唯一の方法です。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









JWTは、JSONに基づくオープン標準であり、主にアイデンティティ認証と情報交換のために、当事者間で情報を安全に送信するために使用されます。 1。JWTは、ヘッダー、ペイロード、署名の3つの部分で構成されています。 2。JWTの実用的な原則には、JWTの生成、JWTの検証、ペイロードの解析という3つのステップが含まれます。 3. PHPでの認証にJWTを使用する場合、JWTを生成および検証でき、ユーザーの役割と許可情報を高度な使用に含めることができます。 4.一般的なエラーには、署名検証障害、トークンの有効期限、およびペイロードが大きくなります。デバッグスキルには、デバッグツールの使用とロギングが含まれます。 5.パフォーマンスの最適化とベストプラクティスには、適切な署名アルゴリズムの使用、有効期間を合理的に設定することが含まれます。

PHP開発における固体原理の適用には、次のものが含まれます。1。単一責任原則(SRP):各クラスは1つの機能のみを担当します。 2。オープンおよびクローズ原理(OCP):変更は、変更ではなく拡張によって達成されます。 3。Lischの代替原則(LSP):サブクラスは、プログラムの精度に影響を与えることなく、基本クラスを置き換えることができます。 4。インターフェイス分離原理(ISP):依存関係や未使用の方法を避けるために、細粒インターフェイスを使用します。 5。依存関係の反転原理(DIP):高レベルのモジュールと低レベルのモジュールは抽象化に依存し、依存関係噴射を通じて実装されます。

システムが再起動した後、UnixSocketの権限を自動的に設定する方法。システムが再起動するたびに、UnixSocketの許可を変更するために次のコマンドを実行する必要があります:sudo ...

記事では、PHP 5.3で導入されたPHPの後期静的結合(LSB)について説明し、より柔軟な継承を求める静的メソッドコールのランタイム解像度を可能にします。 LSBの実用的なアプリケーションと潜在的なパフォーマ

PHP開発でPHPのCurlライブラリを使用してJSONデータを送信すると、外部APIと対話する必要があることがよくあります。一般的な方法の1つは、Curlライブラリを使用して投稿を送信することです。

記事では、入力検証、認証、定期的な更新など、脆弱性から保護するためのフレームワークの重要なセキュリティ機能について説明します。

この記事では、フレームワークにカスタム機能を追加し、アーキテクチャの理解、拡張ポイントの識別、統合とデバッグのベストプラクティスに焦点を当てています。
