mysql - MySQL: ユーザーの「ビュー」のテーブル構造

Question

反対のアドバイスがあった質問があります。追加の意見をいただければ幸いです。

私のサイトには user_id を持つユーザーがいます。これらのユーザーは製品を表示できます。私は、特定の製品を表示しているユーザーの一意のインスタンスを追跡する必要があります。別のビュー テーブルにビューを記録するには、現在 2 つのオプションがあります。

オプション1：

view_id (INT,PK) | user_id (INT,FK) | product_id (INT,FK) | ビュー日付

...そして、ON DUPLICATE KEYで簡単に更新できるように、中央の2つの列に一意の制約を作成します。同じビューが既に存在する場合は、view_date を更新するだけです。そうでない場合は、新しい行を書き込みます。

オプション 2:

ユーザー製品 (VARCHAR20,PK) | ビュー日付

... 2 つの ID を VARCHAR にマージし、途中でセパレーターを使用し、主キー列を使用して、上記と同じ方法で ON DUPLICATE KEY で簡単に更新します。

構造は約まで収容する必要があります。100 万回のユニーク ビュー。どちらのオプションが良いか悪いかについて何か考えがありますか? またその理由は? よろしくお願いします。

編集: 回答ありがとうございます。コンセンサスがあるようです。同じ側​​に傾いていましたが、安心が必要でした。

Answer 1

私は最初のオプションの方が好きです。一般的に、できるだけ多くの原子性を維持するのに適しています。すべてのユーザーのビューなどに対してクエリを実行したい場合、2 つの列を 1 つにマージした後では実行が難しくなります (LIKEワイルドカード マッチを使用する必要がありますが、これは決して高速ではありません)。インデックス付きの単一値列)。また、さまざまなフィールドでインデックスを作成する機能も失われます。

また、複数の列を含む主キーまたは一意のキーを使用できない理由はないため、オプション 2 に利点はないと思います。更新を実行するには、代わりにREPLACE( documentationINSERT ) を使用するだけです。ユーザー/製品の組み合わせごとに 1 つの行しかないという不変条件。

Answer 2

最初のオプションがより良い選択だと思います。後で、さまざまなことのクエリが少し簡単になると思います。文字列操作が含まれないため、クエリも高速になる可能性があります。さらに、必要に応じて、複数の列に主キーを設定できます。

Answer 3

間違いなく最初のオプションを選択してください。2 番目のオプションは、レポートを作成して特定のユーザー グループを検索する必要がある場合、地獄からの多くのクエリを意味します (製品 X と製品 Y を頻繁に表示するすべてのユーザーを取得して、割引を提供できるようにします)。特定のグループを検索する場合も同様です。商品の数 (同じユーザーがよく閲覧する商品で、割引プロモーションを開始できます)

個々の見解をすべて覚えておく必要はないことを理解しています。しかし、私は確かに彼らが製品にアクセスした回数をキャプチャします-これは、実行中の合計を保持できるため、ほとんど無料です（重複キー更新で 1 を挿入、view_count = view_count + 1）