Схема базы данных и запрос для Google Reader-подобного приложения

Question

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

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

Удаление статьи пользователем не влияет на других пользователей;У каждого пользователя есть свой «вид» канала.

Простой подход

Наивная схема, которую я разработал, приведена ниже:

(Конечно, в реальном приложении есть нечто большее, чем отношение пользователя к статье, а не просто сокрытие или пометка звездой.)

Проблема

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

Это означает выбор списка статей.для определенного пользователя - это запрос, который объединяет:

• выбор всех статей, для которых ArticleUserLink не существует;
• выбор всех статей, для которых существует ArticleUserLink иимеет is_hidden = 0.

Является ли OR ответом здесь, или существует более эффективный дизайн / запрос базы данных для решения проблемы?

Answer 1

как насчет использования внутреннего запроса?

SELECT * 
FROM Article a
WHERE NOT EXISTS(SELECT * FROM ArticleUserLink WHERE article_id = a.id AND (is_hidden IS NULL OR is_hidden != 0))

Answer 2

Просто используйте LEFT JOIN

SELECT * 
FROM   Article a
LEFT   JOIN ArticleUserLink ua ON (ua.article_id = a.id)
WHERE  a.user_id = insert_user_id_here
AND    (ua.is_hidden = 0) IS NOT FALSE
...

Таким образом, вы получите

• статей, которые не имеют связанной записи в ArticleUserLink
• статей, которые имеют связанную запись в ArticleUserLink и ua.is_hidden = 0