Mejor estructura de base de datos para almacenar feeds RSS

Question

He estado buscando intentando encontrar una respuesta aquí y en google, aunque he encontrado algunos punteros que aún no he encontrado una solución.

Si usted tiene un lector de RSS simple con una base de datos, es posible que tenga un par de mesas para el almacenamiento de alimentos (ignorando hacer frente a los suscriptores aquí):

• Feeds (feed-id, feed-título , feed-url)
• artículos (artículo -id, feed-id, tema-título, elemento de contenido)

Esto funciona en la mayoría de los casos pero para muchos sitios web/aplicaciones basadas en web puede tener un feed principal desde la página principal y luego feeds de categoría, si toma ambos en el tipo de sistema anterior habrá una gran cantidad de datos replicados debido a la misma publicación que aparece en varios feeds RSS.

Las dos opciones que he encontrado son ignorarlo y aceptar los duplicados o usar una tabla de enlace entre los feeds y los elementos. Pero esto también parece un desperdicio cuando probablemente el 80% del tipo de feeds que estoy buscando extraer no tendrá múltiples feeds que podrían crear esta replicación.

¿Hay una manera mejor de hacer esto/estoy mirando esto de una manera completamente incorrecta?

actualización

Gracias a ambos por las respuestas, por lo que el consenso parece ser que el ahorro en el espacio no es probablemente lo suficientemente importantes como para preocuparse y no se cumpliría el potencial de problemas desconocidos (como mencionado por dbr).

Agregar una tabla de enlaces o similar probablemente también aumentaría el tiempo de procesamiento, por lo que en general no vale la pena preocuparse por demasiado. Después de leer las respuestas de vincular contenido y eliminar duplicados solo tuve pensamientos después de que la publicación ya no está en RSS feed para ahorrar espacio, pero como dijo Assaf, el ahorro de espacio podría hacer que esto sea una pérdida de tiempo.

Answer 1

Sugiero que no intente optimizar todas las copias posibles de datos de feeds en esta etapa de desarrollo (diseño, supongo). Concéntrese en hacerlo funcionar y, cuando termine, si hace algún perfil y descubre que efectivamente puede guardar X% de almacenamiento si usa enlaces o datos compartidos entre alimentaciones, solo entonces y si X es grande lo suficiente como para pagar el tiempo que llevaría optimizar su DB, le sugiero que implemente cualquiera de estos esquemas más avanzados.

Answer 2

Como dijo Assaf, no me preocuparía almacenar artículos duplicados si provienen de diferentes fuentes, al menos por ahora. La complicación que agregaría no beneficia los pocos kilobytes de espacio que guardaría ...

Supongo que si toma un sha1 de contenido, haga SELECT id FROM articles WHERE hash = $hash y si algo existe, simplemente tenga un "article_content_id" que si establece puntos el contenido de los artículos en otra fila ... pero, ¿qué pasa si tiene dos artículos:

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 

..esto funciona bien, y ha guardado 3 bytes al no duplicar el artículo (obviamente más si el artículo fue más largo)

..pero qué sucede cuando Bob decide agregar anuncios a su fuente RSS, cambiando el contenido de Hi! a Hi!<p><img src='...'></p> - pero Planet Randompeople elimina todas las imágenes. Luego, para actualizar un elemento de alimentación, debe verificar cada fila que content_link_id -relacione con el artículo que está actualizando, compruebe si el nuevo elemento tiene el mismo hash que los artículos que lo vinculan; si es diferente, tiene que romper el enlace y copia los datos antiguos al elemento de enlace, luego copia el contenido nuevo al elemento original ..

Hay formas posiblemente más ordenadas de hacerlo, pero mi punto es que puede ser muy complicado, y lo harás probablemente sólo ahorrar unos cuantos kilobytes (suponiendo que el motor de base de datos no hace ningún tipo de compresión en sí) en un subconjunto muy limitado de puestos ..

Aparte de eso, tener una tabla de feeds y items parece sensato, y es la forma más otras bases de datos de almacenamiento RSS que he visto tratado con él ..