0

アプリ内のページのツアーを再度表示するブラウザーが異なるため、クライアント側の Cookie を回避しようとしています。

ユーザーは、最初に見たときにのみツアーを見る必要があります。それから私はこのような表で考えています：

表:ユーザー x pages_that_viewed

user_id      seen_page         seen_profile        seen_another_page...

  12         2012-12-12 

  13         2012-12-12         2012-12-12

次に、毎回これでテーブルユーザーに参加する必要があります...

別の解決策は、この列を users テーブルに直接追加することです。

4

3 に答える 3

2

所有しているページ数と追加を計画しているページ数に応じて、ページを追加するたびにデータベース スキーマの変更が必要になります。一般的に言えば、それは良い考えではありません。代わりに、ページごとにユーザーごとに 1 つのレコードを作成できます。user_id、page_id のインデックス。いつアクセスしたかを知りたい場合は、3 番目のフィールドが日付になります。それ以外の場合はブール値になります。もう 1 つの方法はビットマップを使用することですが、日付が必要な場合は機能しませんが、すべてのユーザーの訪問を追跡するためにページごとに 1 つのレコードしか必要としません。

ビットマップ フィールドは、この 001000100011110010 のようなものを格納します。各数字は user_id を表し、そのページへの訪問を格納します。元。user_id 12、12 桁目は 0 または 1 などになります。訪問時に、1 つのフィールドを更新し、N 桁目を 1 に設定します。ビットマップは一般に非常に高速で、ユニオン、交差などの追加操作をサポートします。

于 2012-09-18T16:03:19.163 に答える
2

列の方が費用対効果が高く、クエリがはるかに少ないと思います...

ブール値のツアー列を試してから、誰かがアプリにログインしたら、列を取得してセッションに保存します

session[:tour] ||= @user.tour
于 2012-09-18T16:04:21.113 に答える
0

あなたの最後のコメントを読んだ後、私はこのアイデアを思いついた、私はあなたが多対多の関連付けになるユーザーとページの関係を作るべきだと思う、そしてあなたは列user_idとpage_idを持つジャンクションテーブルpages_usersを持つことができ、そして各レンダリングで現在のユーザーが現在のページを持っているかどうかを確認します。それが最善の方法だと思います。

于 2012-09-18T16:52:25.957 に答える