2009-06-12 5 views
0

Предположим, что в базе данных есть таблицы для пользователей, фидов, элементов и возможность узнать, какие элементы пользователь уже видел. Я ищу парадигму дизайна, которая может быть использована на сервере для вычисления за короткий промежуток времени [идентификатор фида, num_unread] для каждого канала, на который подписался пользователь.Что было бы хорошим алгоритмом для учета количества непрочитанных элементов В реализации агрегатора онлайн-подачи?

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

Редактировать: Я хотел решить проблему, которую Ник J поднял (см. Ниже). Но я ценю решение, размещенное cletus. Меня не так беспокоят запросы db, но вы хотите «парадигму дизайна» - например, следить за тем, чтобы отслеживать процесс, который хранит непрочитанные подсчеты в памяти, чтобы он мог обслуживаться в любой момент.

ответ

1

Я не уверен, что именно вам сказать, потому что то, о чем вы просите, достаточно прост.

Прежде всего, используйте Google Reader в качестве справочника для агрегаторов/считывателей онлайн-каналов. И если вы пытаетесь воссоздать функциональность, Google Reader в значительной степени пригвоздил ее (imho).

Google Reader работает просто, сохраняя список каналов. С точки зрения БД, вы, вероятно, есть эти сущности

User: id, name, email, etc... 
Feed: id, feed_name, feed_url 
Content: id, feed_id, title, content 
User Feed: id, user_id, feed_id, user_label, has_read 

непрочитанные элементы:

SELECT COUNT(1) 
FROM user u 
JOIN user_feed uf ON uf.user_id = u.id 
JOIN feed f ON f.id = uf.feed_id 
WHERE has_read = 0 

непрочитанные элементы по корма:

SELECT feed_id, feed_name, COUNT(1) 
FROM user u 
JOIN user_feed uf ON uf.user_id = u.id 
JOIN feed f ON f.id = uf.feed_id 
WHERE has_read = 0 
GROUP BY feed_id, feed_name 

И тогда вам просто нужно какой-то механизм для маркировки предметов как прочитано. В случае с Google Reader есть только вызовы AJAX, вызванные событиями mouseover, с дополнительными ссылками, чтобы пометить все как прочитанные, оставить элемент, отмеченный как непрочитанный, и так далее.

+0

Проблема, которую вам не хватает, заключается в том, что подсчет непрочитанных элементов во время выполнения крайне неэффективен - O (n) для количества непрочитанных элементов - и, следовательно, непрактично в больших масштабах. Подход читателя к этому заключается в том, чтобы наложить кол-во на количество непрочитанных элементов, которые он будет считать. –

+0

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

+0

Я просто добавлю, что на самом деле важно, чтобы вы получили прочный дизайн. Тогда и только тогда вы оптимизируете его, если и только если вам нужно. В этом случае вы можете денормализовать модель, сохранив непрочитанные счета в пользовательской фиде, но не начинайте это. Это означает, что вам нужно иметь дело с проблемами обновления значений в двух таблицах, когда элемент читается, а значения могут выйти из синхронизации. – cletus