Лучшая структура базы данных для хранения RSS-каналов

Question

Я искал вокруг, пытаясь найти ответ и здесь, и в Google, хотя я нашел несколько указателей, которые я не совсем нашел решение.

Если у вас есть простая программа чтения RSS с базой данных, у вас может быть пара таблиц для хранения каналов (игнорируя работу с подписчиками здесь):

• Feeds ( feed-id , feed-title, питательная URL)
• Items ( item-id , feed-id , item-title, item-content)

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

Два варианта, которые я выбрал, это либо игнорировать их и принимать дубликаты, либо использовать таблицу ссылок между каналами и элементами. Но это также кажется довольно бесполезной тратой, когда, вероятно, у 80% каналов, которые я ищу, не будет нескольких каналов, которые могли бы создать эту репликацию.

Есть ли лучший способ сделать это / я смотрю на это совершенно неправильно?

Update

Спасибо обоим за ответы, поэтому, по-видимому, все согласны с тем, что экономия на пространстве, вероятно, недостаточно значительна, чтобы о ней беспокоиться, и будет сведена на нет потенциальной возможностью неизвестных проблем (таких как упомянутое dbr).

Добавление таблицы ссылок или аналогичной информации, вероятно, также увеличит время обработки, так что в целом не стоит слишком беспокоиться. У меня возникли мысли после прочтения ответов о связывании контента и удалении дубликатов, только когда сообщение больше не находится ни в одном из RSS-каналов для экономии места, но опять же, как сказал Ассаф, экономия пространства может сделать это пустой тратой времени.

Answer 1

Я бы посоветовал вам не пытаться оптимизировать каждую возможную копию данных фида на данном этапе разработки (я полагаю, дизайн). Сконцентрируйтесь на том, чтобы заставить его работать и когда вы закончите, если вы выполните какое-либо профилирование и обнаружите, что действительно можете сэкономить X% хранилища, если используете ссылки или общие данные между каналами, только тогда и если X достаточно велик, чтобы заплатить за время, необходимое для оптимизации вашей БД я бы предложил вам внедрить любую такую ​​более продвинутую схему.

Answer 2

Как сказал Ассаф, я не буду беспокоиться о хранении дублированных статей, если они приходят из разных каналов, по крайней мере сейчас. Сложность, которую это добавит, не принесет пользы тем небольшим килобайтам пространства, которые вы сэкономите.

Полагаю, если вы берете хэш sha1 содержимого, выполните SELECT id FROM articles WHERE hash = $hash и, если что-то существует, просто укажите "article_content_id", который, если установить, указывает содержимое статьи в другой строке ... но что, если у вас два статьи:

id: 1
title: My First Post!
feed: Bobs site
content: Hi!
hash: abc
link: no
content_link_id:

id:2
title: My First Post!
feed: Planet Randompeople Aggregator
content:
hash: abc
content_link_id: 1

.. это работает нормально, и вы сэкономили 3 байта, не дублируя статью (очевидно, больше, если статья была длиннее)

.. но что происходит, когда Боб решает добавить рекламу в свой канал RSS, изменяя содержимое с Hi! на Hi!<p><img src='...'></p> - но Planet Randompeople удаляет все изображения. Затем, чтобы обновить элемент фида, вы должны проверить каждую строку, которая content_link_id ссылается на статью, которую вы обновляете, проверить, имеет ли новый элемент тот же хэш, что и статьи, ссылающиеся на него - если он другой, у вас есть разорвать ссылку и скопировать старые данные в элемент ссылки, а затем скопировать новое содержимое в исходный элемент.

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

Кроме этого, наличие таблицы feeds и items кажется разумным, и именно так справлялись большинство других баз хранения RSS, которые я видел ..