MySQL: структура таблицы для "представлений" пользователя
У меня есть вопрос, на который я дал несколько советов, буду признателен за дополнительные мнения.
На моем сайте есть пользователи, у каждого из которых есть user_id. Эти пользователи могут просматривать продукты, и мне нужно отслеживать уникальные случаи, когда пользователи просматривают определенные продукты. Чтобы записать представление в отдельную таблицу представлений, у меня есть два варианта:
ОПЦИЯ 1:
view_id (INT, PK) | user_id (INT, FK) | product_id (INT, FK) | view_date
... и создайте уникальное ограничение для двух средних столбцов для легкого обновления с помощью клавиши ON DUPLICATE. Если такой же вид уже существует, я просто обновляю view_date. Если нет, я пишу новую строку.
ВАРИАНТ 2:
user_product (VARCHAR20, PK) | view_date
... объединить два идентификатора в VARCHAR с разделителем в середине и использовать столбец первичного ключа для простого обновления с помощью клавиши ON DUPLICATE KEY таким же образом, как указано выше.
Структура должна вместить до прибл. миллион уникальных просмотров. Любые мысли о том, какой вариант может быть лучше или хуже, и почему? Большое спасибо заранее.
РЕДАКТИРОВАТЬ: Спасибо за ответы, кажется, что есть консенсус. Наклонился в ту же сторону, но просто нуждался в заверении.
3 ответа
Мне больше нравится первый вариант - в общем, он хорош, чтобы поддерживать как можно больше атомности. Если вы когда-нибудь захотите запросить все представления пользователя или что-то в этом роде, сделать это будет сложнее после объединения двух столбцов в один (вам нужно будет использовать LIKE с подстановочным соответствием, которое никогда не будет таким же быстрым, как индексированный однозначный столбец). Вы также теряете возможность индексировать по разным полям.
Кроме того, нет никаких причин, по которым у вас не может быть первичного или уникального ключа, включающего несколько столбцов, поэтому я не вижу преимуществ перед вариантом 2. Чтобы выполнить обновление, просто используйте REPLACE ( документация) вместо INSERT - это позволит вам легко поддерживать свой инвариант наличия только одной строки на комбинацию пользователь / продукт.
Я думаю, что первый вариант - ваш лучший выбор. Позже я думаю, что это немного упростит запросы на разные вещи. Скорее всего, запросы будут выполняться быстрее, так как в них не будет задействована обработка строк. Кроме того, вы можете иметь первичный ключ для нескольких столбцов, если вам нужно.
Обязательно зайдите на первый вариант. Второй вариант будет означать множество запросов из ада, если вам нужно создавать отчеты для поиска определенных групп пользователей (предоставьте мне всех пользователей, которые часто просматривают продукт X и продукт Y, чтобы мы могли предложить им скидку), то же самое для поиска определенных групп продуктов (какие продукты часто просматривают одни и те же пользователи, поэтому мы можем запустить скидку)
Я понимаю, что не обязательно помнить все индивидуальные взгляды. Но я бы наверняка зафиксировал количество посещений продукта - это почти бесплатно, так как вы можете сохранить промежуточный итог (вставить 1, при обновлении дублированного ключа view_count = view_count + 1)