MySQL: структура таблиц для "представлений" пользователя

Question

У меня есть вопрос, на который я дал несколько советов, буду признателен за дополнительные мнения.

На моем сайте есть пользователи, у каждого из которых есть идентификатор_пользователя. Эти пользователи могут просматривать продукты, и мне нужно отслеживать уникальные случаи, когда пользователи просматривают определенные продукты. Чтобы записать представление в отдельную таблицу представлений, у меня есть два варианта:

ВАРИАНТ 1:

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

... и создайте уникальное ограничение для двух средних столбцов для легкого обновления с помощью клавиши DUPLICATE. Если такой же вид уже существует, я просто обновляю view_date. Если нет, я пишу новую строку.

ВАРИАНТ 2:

user_product (VARCHAR20, PK) | view_date

... объединить два идентификатора в VARCHAR с разделителем в середине и использовать столбец первичного ключа для легкого обновления с помощью ключа DUPLICATE, как описано выше.

Конструкция должна вместить до прибл. миллион уникальных просмотров. Есть мысли о том, какой вариант может быть лучше или хуже, и почему? Большое спасибо заранее.

EDIT: Спасибо за ответы, похоже, что есть консенсус. Наклонился в ту же сторону, но просто нуждался в успокоении.

Answer 1

Мне больше нравится первый вариант - в общем, он хорош для поддержания как можно большего количества атомарностей. Если вы когда-нибудь захотите запросить все представления пользователя или что-то в этом роде, сделать это будет сложнее после объединения двух столбцов в один (вам нужно будет использовать LIKE с подстановочным соответствием, которое никогда не будет быстрый как индексируемый однозначный столбец). Вы также теряете возможность индексировать различные поля.

Кроме того, нет причин, по которым у вас не может быть первичного или уникального ключа, включающего несколько столбцов, поэтому я не вижу преимуществ перед вариантом 2. Чтобы выполнить обновление, просто используйте REPLACE ( документация ) вместо INSERT - это позволит вам легко поддерживать свой инвариант наличия только одной строки на комбинацию пользователь / продукт.

Answer 2

Определенно перейдите на первый вариант. Второй вариант будет означать множество запросов из ада, если вам нужно создавать отчеты для поиска определенных групп пользователей (предоставьте мне всех пользователей, которые часто просматривают продукт X и продукт Y, чтобы мы могли предложить им скидку), то же самое для поиска определенных групп продуктов (какие продукты часто просматривают одни и те же пользователи, поэтому мы можем запустить скидку)

Я понимаю, что не обязательно помнить все отдельные взгляды. Но я бы наверняка зафиксировал количество посещений продукта - это почти бесплатно, так как вы можете сохранить промежуточный итог (вставить 1, при обновлении дубликата ключа view_count = view_count + 1)

Answer 3

Я думаю, что первый вариант - ваш лучший выбор. Позже я думаю, что это сделает запросы к разным вещам немного легче. Скорее всего, запросы также будут выполняться быстрее, поскольку в них не будет задействована обработка строк. Кроме того, вы можете иметь первичный ключ для нескольких столбцов, если вам нужно.