У кого из моих друзей такое же «лайк»? - PullRequest
1 голос
/ 27 июля 2010

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

pizza.html
hamburger.html
etc..

Если я являюсь пользователем A и смотрю страницу pizza.html, я хотел бы узнать, у кого из моих друзей естьтакже «понравилась» эта страница.Предполагая, что я хочу показать это, когда я загружаю pizza.html, я могу сделать это по требованию очень болезненно, например:

User me;
Like current = "pizza.html";
List<User> friendsWhoAlsoLikePageImLookingAt;
for (User friend : me.getFriends()) {
    for (Like like : friend.getLikes()) {
        if (like == current) {
            friendsWhoAlsoLikePageImLookingAt.add(friend);
        }
    }
}

// now friendsWhoAlsoLikePageImLookingAt contains all of my
// friends that like the page I'm viewing.

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

Другой подход состоял бы в том, чтобы предварительно рассчитать все лайки для каждого пользователя (я думаю, что это не будет так хорошо масштабироваться).Например, каждый пользователь получает свой собственный текстовый файл для каждого интереса, например:

userA_pizza.txt
userB_pizza.txt
userA_hamburger.txt
userB_hamburger.txt
...

, предполагая, что я дружу с пользователем B, а userB добавляет «pizza.html» как новый лайк - тогда я бы обновил userA_pizzaTXT-файл, который будет выглядеть так:

// userA_pizza.txt
userB  // latest friend to also like this interest.
userX  // previous friend likes
userY  // previous friend likes

Теперь, когда я (userA) просматриваю страницу с пиццей, я могу открыть 'userA_pizza.txt' и просто сбросить все имена друзей без каких-либо вычислений.Теперь каждый раз, когда пользователю нравится страница, мне приходится обновлять N TXT-файлов, где N - количество их друзей.Кроме того, каждому пользователю потребуется текстовый файл для каждого возможного интереса (и может быть тысячи интересов).Если у пользователя есть 100 000 друзей, и у каждого из них есть 1000 интересов, это также может быть очень дорогостоящим!

Да, так что любые идеи или мысли были бы замечательными -

Спасибо

Ответы [ 3 ]

2 голосов
/ 27 июля 2010

Не могли бы вы просто сохранить список на "лайк" странице, для которой людям это понравилось? Затем вместо того, чтобы проходить все «лайки» для каждого друга для текущего пользователя, вы можете просто просмотреть пользователей, которым понравилась страница, на которой он находится в данный момент, и перечислить только те, которые являются друзьями текущего пользователя.

По-прежнему неэффективно и не удивительно для масштабирования, но в этом случае, когда пользователю нравится страница, вам нужно обновить только «понравившуюся» страницу, а не целую кучу страниц. Вы ограничены только текстовыми файлами? База данных может сделать это очень просто.

1 голос
/ 27 июля 2010

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

У вас может быть таблица пользователей, содержащая самих пользователей, таблица userFriends, связывающая пользователей с друзьями, таблица лайков (одна строказа симпатичную вещь), таблица userLikes связывает пользователей с тем, что им нравится.

Тогда мне будет намного проще поддерживать запрос к базе данных, чтобы создать набор записей того, что нравится друзьям пользователя.

0 голосов
/ 28 июля 2010

Предполагая, что ваш сервер является базой данных, у вас должно быть 3 таблицы, на которые ссылаются для этой функции

User table (Id, Name, etc) 
Page table (Id, Url, etc)
LikedPages (UserId, PageId)

Вы можете запросить таблицу LikedPages по UserId, чтобы увидеть список всех лайков для одного пользователя.Вы также можете выполнить запрос к PageId, чтобы узнать, кому нравится эта страница.Пересечение этих двух запросов - результат, который вы ищете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...