MySQL: Estrutura da tabela de “vistas” de um usuário

Question

Eu tenho uma pergunta para a qual eu tive conselhos oposição, iria apreciar vistas adicionais.

Meu site tem usuários, cada um com um user_id. Esses usuários podem visualizar os produtos, e eu preciso de manter o controle das instâncias exclusivas de usuários que visualizam produtos específicos. Para gravar uma exibição em uma tabela de pontos de vista em separado, eu tenho atualmente duas opções:

OPÇÃO 1:

view_id (INT, PK) | user_id (INT, FK) | product_id (INT, FK) | view_date

... e criar uma restrição exclusiva sobre as duas colunas do meio para fácil actualização com ON DUPLICATE KEY. Se a mesma visão já existe, eu só atualizar view_date. Se não, eu escrevo uma nova linha.

Opção 2:

user_product (VARCHAR20, PK) | view_date

... fundir os dois ids em um VARCHAR com um separador no meio, e usar a coluna de chave primária para fácil actualização com ON DUPLICATE KEY da mesma forma como acima.

A estrutura deve acomodar até aprox. milhões de visualizações exclusivas. Quaisquer pensamentos sobre qual opção pode ser melhor ou pior, e por quê? Big obrigado antecipadamente.

EDIT: Obrigado pelas respostas, parece que há um consenso. Estava inclinado para o mesmo lado, mas só precisava da segurança.

Answer 1

Eu como a primeira opção melhor - em geral, é bom para manter o máximo atomicity possível. Se você quiser consulta para todos os pontos de vista de um usuário, ou algo parecido, seria mais difícil fazer depois de fundir duas colunas em um (você precisaria usar LIKE com um coringa, que nunca será tão rápido quanto um indexado coluna de valor único). Você também perdem a capacidade de índice em diferentes campos.

Além disso, não há nenhuma razão para que você não poderia ter uma chave primária ou única que envolveu várias colunas, então eu não vejo nenhuma vantagem para a opção 2. Para realizar a atualização, basta usar REPLACE ( documentação ) em vez de INSERT - isso permitirá que você facilmente manter o seu invariável de ter apenas uma linha por user / combinação de produto.

Answer 2

Eu acho que a primeira opção é a sua melhor escolha. Mais tarde para baixo da linha eu acho que ele vai fazer a consulta para coisas diferentes um pouco mais fácil. Consultas provavelmente vai ser também mais rápida uma vez que não será a manipulação de cadeia envolvida. Além disso, você pode ter uma chave primária sobre várias colunas, se você precisa.

Answer 3

Definitivamente ir para a primeira opção. A segunda opção vai significar muitas consultas do inferno se você precisa fazer relatórios de olhar para grupos específicos de usuários (me todos os usuários que muitas vezes vêem os produtos X e Y para que possamos oferecer-lhes um desconto), mesmo para olhar para grupos específicos de produtos (quais produtos são muitas vezes vistos pelos mesmos usuários, para que possamos lançar uma promoção de desconto)

Eu entendo que não é um requisito para lembrar todos os pontos de vista individuais. Mas eu certamente capturar o número de vezes que visitou o produto - este é quase de graça, como você pode manter uma execução total (insert 1, em duplicado view_count atualização key = view_count + 1)