Base de datos MySQL + XML portal tipo "Blogger"

[kolom]

En el proyecto "final" he decidido hacer un portal al estilo "blogspot , mySpace..." pero tengo una duda sobre como dissenyar la base de datos.

- Para almacenar cada configuración de usuario i los archivos subidos se crea una carpeta por usuario con su respectivo xml con la configuració (titulo, subtitulo, template.. etc)

¿Porque usar xml y no la base de datos directamente?
El usuario podrá añadir/borrar bloques y asi me ahorro campos inecesarios de la BBDD solo se crean y se destruien los xml segun bloque que actives.

EL mysql lo utilizaria para el login, nombre de usuario, pass, email, y carpeta del usuario.

Ahora viene mi gran duda.. donde creen que es mejor almacenar los "post" de cada usuario en un xml como el de la configuración (aunque si tiene por ejemplo 200 post el xml puede engordar muchiiiisimo), o directamente en la BBDD aunque si lo pongo en una misma tabla todas las entradas de los usuarios seria enorme! y crear una tabla por usuario también crearia una base realmente grande.

Alguna idea de cual sería la mejor forma? GRACIAS

[gnzsoloyo]

Creo que tienes una visión errada del uso del XML y de las bases de datos en el contexto de un sistema de blogs.

A mi entender es totalmente equivocado usar XML para almacenar datos que deberían ser estructuras de la base, simplemente porque dices "asi me ahorro campos inecesarios de la BBDD solo se crean y se destruien los xml segun bloque que actives." Eso muestra que no manejas muy bien el modelo relacional, ya que en ese caso sabrías que bloques que se activan y desactivan se desarrollan en el modelo como tablas y relaciones de determinado tipo.

El hecho de que determinados valores estén o no, no implica la creación de columnas en tablas, sino su aparición en determinadas relaciones. El uso de bases de datos es una de las cosas que le presta flexibilidad a los blogs, ya que no dependerían de la programación para cambiar los esquemas. Simplemente se cargan nuevos.

A mí me da la impresión de que no has desarrollado un buen modelo E-R lógico, y que realmente no has determinado correctamente las entidades y sus relaciones, por lo que la aplicación de la base de datos física se te está escapando de las manos y buscas una forma alternativa, que a la larga será menos efectiva.

En cualquier caso, puedo decirte que todo lo que necesitas para administrar ese servicio podría ser a través de la base de datos, sin usar jamás un XML y aún así sería dinámico y eficiente.

[kolom]

Muchas gracias por tu respuesta...

Quizas no me expresado correctamente y en parte tienes toda la razon jeje

Te comento... originalmente desarrolle un modelo E-R (si tengo tiempo y lo paso a limpio lo cuelgo, que actualmente la tengo solo en papel).

Lo de xml es como muy bien dices "una chapuzilla" ya que encontraba que albergar todos los mensajes de los usuario en una tabla y relacionarlos con el id del usuario crearia una tabla realmente grande y pensé que con el xml y creando uno por usuario crearia un estilo mas eterogenio.

Aunque viendo BBDD realmente grandes como puede ser un foro tipo SMF que lo alberga todos sus mensajes en la tabla "smf_messages" no creo que afecta tanto el rendimieno no?

Realmente creo que abandonaré la idea de los xml.

[gnzsoloyo]

Lo de xml es como muy bien dices "una chapuzilla" ya que encontraba que albergar todos los mensajes de los usuario en una tabla y relacionarlos con el id del usuario crearia una tabla realmente grande y pensé que con el xml y creando uno por usuario crearia un estilo mas eterogenio.

Si. Como dices, es muy posible que se termine generando una tabla realmente grande, aunque en este caso el incremento de la tabla, que a nivel de InnoDB no tiene un límite, se puede administrar depurando la misma con ayuda de un datawerehouse que permita separar datos "históricos" en cada proceso de mantenimiento, sacando de esa forma de la base principal, lo que en definitiva "alivianaría" la tabla.
Un detalle que debes tener en cuenta es que ese tipo de problemas recién se pone de manifiesto cuando la tabla en cuestión llega a ser realmente grande, o sea, en el orden de muchos Gb...
Otra solución es tratar de ver si los post y las respuestas pueden estar representando entidades diferentes en algunos casos. Esto implicaría que el peso de los posts podría repartirse en diferentes tablas, según el caso.
Finalmente, tienes dos alternativas para controlar el asunto: Hacer una base distribuida, o replicarla para que las consultas puedan ser optimizadas por otros medios.
En fin. Si el problema es la sobrecarga de una tabla (ya lo he sufrido en unas aplicaciones), existen otros planes de contingencia posibles.

MI principal objeción sobre el uso de archivos planos para mantener ese tipo de configuraciones, es que se genera una dependencia demasiado estricta a un modelo de datos, ya que cualquier cambio o adición posible en ese modelo implicará eventualmente la modificación tanto de los XML como de la aplicación misma. solucionas un problema "pequeño" y te crearás uno muy grande a mi entender.

Sugerencia: Usa el buscador del foro y fíjate sobre el tema de diseño de paginas con administración de post y usuarios. En los últimos dos meses hubo varios donde se trató el tema de una forma bastante detallada.