ユーザーの将来の検索のために、Web サイトにいくつかの履歴情報を保存しています。そのため、特定のページにアクセスすると、アクセスしたページと時間を記録し、将来の追加/取得のためにユーザー ID の下に保存します。
したがって、私の最初の計画は、すべてのデータを配列に格納し、取得するたびにシリアル化/非シリアル化してから、データベースの TEXT フィールドに格納することでした。問題は、ユーザーが (たとえば) 10,000 ページの履歴を作成した場合に、大量のデータ配列でこれがどれほど効率的か非効率的かがわからないことです。
編集:これを行う最も効率的な方法を知りたいですか? また、すべての履歴に対してデータベースに新しい行を挿入することも検討していましたが、そうすると、物事を選択するための大きなデータベースが作成されます。
問題は、データベース内のより高速で効率的な大量の行または大量のシリアル化された配列のどちらですか? 他のより良い解決策は明らかに歓迎されています。最終的には Python に切り替える予定ですが、現時点では PHP で行う必要があります。
データをシリアル化された配列として格納するメリットはありません。データの大きなブロブの取得、逆シリアル化、変更、および更新のための再シリアル化は遅くなります。さらに悪いことに、データの断片が大きくなるほど（正確に心配していること）遅くなります。
データベースは、多数の行を処理するように特別に設計されているため、それらを使用してください。提案された方法とは異なり、データが大きくなるにつれて挿入ごとの追加コストは発生せず、同じ量のデータを保存しているので、データベースに最善を尽くさせ、コードをシンプルに保ちます。
データを配列として保存すると、あらゆる種類のクエリや集計がほぼ不可能になります。システムの目的が（たとえば）特定のページにアクセスした回数を確認することである場合は、すべてのレコードを逆シリアル化し、一致するすべてのページを検索する必要があります。ユーザーとページ、それは些細なSQLカウントクエリです。
ある日、行が多すぎて（10,000は行数が多くない）、パフォーマンスの問題が発生し始めた場合は、おそらく集計と非正規化を通じて、それを最適化する方法を見つけてください。
セッション変数を確認し、1 つのセッションのすべてのデータを保存して、データベースにまとめてダンプできます。
時間を節約するために、db レベルでインデックス作成を行うことができます。
最後にできる最も効果的なことは、データに対して操作/操作を実行し、それを別のテーブルに保存することです。そして、常に操作されたテーブルからデータを選択します。これは、cron ジョブまたはスケジュールを使用して実現できます。