Активность пользователя структура базы данных

Question

Я работаю над сайтом сообщества. Я хочу показать активность пользователя в места на сайте.

1. Профиль пользователя «А».
2. Страница друзей пользователя «A» друзей. «Что делают ваши друзья?»

---

Таблицы для экземпляра являются:

• члены
• members_gallery
• members_videos
• members_friends

---

Моя проблема заключается в структуре Sql. Я прочитал этот вопрос "User recent activities - PHP MySql"

Идея «союза» хороша, но у меня есть альтернативный вариант. Я собираюсь сделать новую таблицу под названием

• members_activity

Поля:

id | user_id | photo | video | friend | p_id | v_id | f_id | datetime 

давайте предположим, что пользователь имеет только загрузил изображение.

id | user_id | photo | video | friend | p_id | v_id | f_id | datetime 
1 | 15 | 1 | 0 | 0 | 1203 | 0 | 0 | NOW() 

преимущества:

• Когда я сделать запрос на выборку, я могу легко узнать, если это фото, видео, или дружба деятельность.
• Пользователь может удалить «активность фото», но сохранить фотографию.
• Может легко уведомлять друзей о пользователе.

недостатки:

• Огромное количество строк таблицы?

Любые идеи или предложения по поводу того, как с этим связаны крупные сайты? digg, facebook и т. д.

Answer 1

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

id | user_id | activity_type_id | p_id | v_id | f_id | datetime 

Вы можете видеть, что я заменил видео, фото и т.д. с activity_type_id. Тогда будет вторая таблица называется activity_types:

id | name 
----+------- 
    1 | photo 
    2 | video 
    3 | ... 

Тогда при создании members_activity записи можно назначить соответствующую activity_type_id, и если вы хотите, чтобы создать новые виды деятельности в дальнейшем это относительно безболезненно, и вы могли бы SELECT конкретный вид деятельности с простым JOIN, например:

SELECT * FROM members_activity 
    JOIN activity_types ON members_activity.activity_type_id = activity_types.id 
WHERE activity_types.name = 'photo'; 

Answer 2

Если у вас огромное количество строк, это действительно не будет практическим недостатком, если вы правильно индексируете таблицу.

По крайней мере, я бы проиндексировал user_id и datetime, предполагая, что вы будете выбирать активность для определенного пользователя и заказывать по дате.

Используйте MySQL EXPLAIN (<query>), чтобы гарантировать, что ваши индексы оптимизированы для часто задаваемых запросов.

Answer 3

• Я не понимаю, зачем вам нужен идентификатор друзей. Для страницы друзей вы сначала сделаете выбор для всех своих друзей, затем выберите из таблицы действий, где user_id в (2,6,89 и т. Д.)

• Я бы сделал фото и видео поля одним полем типа, где фото и видео будет значения, таким образом, вы можете позже добавить больше видов деятельности

• Я бы p_id и v_id один столбец item_id .. нет необходимости в 2 колонки

• Я хотел бы добавить дополнительный столбец с именем info, где я буду хранить другую информацию в формате json. Это касается дополнительных данных, которые не все события имеют. Например, у вас может быть событие для добавления ссылки на профиль ... и вы можете поместить туда ссылку, поскольку другие события не имеют URL-адресов, а добавление столбца только для этого типа событий было бы не лучшим решением.