Elección de base de datos

Uffff creo que te estoy liando, a ver si consigo explicartelo mejor :D.
Tu en realidad puedes utilizar xml en cualquier caso cuando es con flash es casi obligatorio porque no lee directamente de mysql y necesitamos una plataforma intermedia que lea los contenidos de mysql, aunque tambien podemos leer variables que hemos imprimido en php o asp, pero eso te limita un poco la operancia de tu aplicacion.
Cuando utilizas un lenguaje servidor como por ejemplo php para armar tu site puedes leer los contenidos de un xml por supuesto y sin problemas y es cierto que queda una copia almacenada en cache mientras el usuario esta navegando, pero la velocidad que ganas es tan imperceptible que a mi por lo menos no me merece la pena tirar por esa opcion, hago las consultas necesarias a mysql que esta muy bien estructurada y tira muy rapidita y aqui paz y despues gloria con eso lo que te comentaba antes de que te quitabas algunas movidillas de patchear los xml´s desde php por ejemplo

entonces usar a la vez el xml al vuelo, se restringe a cuando usemos flash, no?

pueden existir casos en los que la base de datos no cambie mucho, como que ponía arriba del todo, en tales casos el xml queda en caché y es mejor, no?

hombre con lo de que ganarias en velocidad consultando el xml en vez de la base de datos, es relativo volvemos al numero de consultas y como esten compuestas esas consultas. yo te recomiendo que directamente llames a la base de datos te vas a quitar algun follon que otro. yo no noto mucha diferencia en velocidad cuando realizo consultas a esos dos soportes y si por ejemplo necesitas tener los datos separados olvidate de tenerlo todo en el mismo xml porque eso se convertiria en un caos.

yo tiraria de base de datos directamente la velocidad no la vas a apreciar

lo de (1) generar al vuelo lo comprendo bien y sería sobre todo para flash, no? en html como comentas basta con consultar a la base de datos

lo de (2) lo que proponía era usar (si las restricciones lo permitiesen) una consulta a un fichero xml donde se encuentren los datos (1 sóla vez, en lugar de múltiples accesos a la base de datos), de esta forma se ganaría velocidad, no? (dependiendo del contexto)

lo de (3) entiendo que sería esto más bien para proyectos personales, las restricciones del cliente suelen requerir actualizaciones inmediatas; aunque en el caso de catálogos, se podría también volcar cada noche al fichero xml automáticamente, esta técnica sería para usarla sólo cuando la actualización inmediata no sea un problema (o bien usar las dos a la vez, páginas con actualización inmediata y consultas a la base de datos, y páginas con 1-15 días de obsolescencia que consulten el xml si así se ganara velocidad)

david_chueca_18 @ yahoo.es

davidchueca, creo que no nos has entendido muy bien, te explico
1º generar xml al vuelo, se dice asi porque se generan en el mismo momento de la consulta y se generan por ejemplo desde php si tienes una base de datos mysql, flash es capaz de interpretar un xml que esta incrustado dentro de php de ahi el termino generar al vuelo.

2º lo de ganar velocidad es una cuestion de las dimensiones de la pagina y de la cantidad de consultas simples, cruzadas, o inserciones multitabla que necesites hacer en la web si son muchas con mucha informacion 200 usuarios conectados a la vez podrian llegar a colapsar el servidor, con lo cual en determinadas circunstancias si que se puede ganar velocidad, generando los xml´s en el momento en que el usuario sube contenido a la base de datos.

Todo esto suponiendo que introduces los datos en flash, si directamente los datos los presentas en HTML, el problema se reduce a la minima expresion, realizas la consulta a la base de datos desde el mismo html, y ordenas los datos recogidos ahi mismo, yo lo suelo hacer mediante arrays pero eso como todo es una cuestion de gustos.

3º podrias generar los xml´s cada 15 dias sin problemas incluso generarlos a mano tampoco seria descabellado, pero con ello eliminas presencia inmediata de los contenidos que tu cliente sube a la base de datos

espero que con esto te halla solucionado algo, de todas formas si quieres nos cambiamos los mails mediante un privado y te paso ejemplos para que lo veas mas claro.

a ver, la idea sería tener una base de datos mysql por ejemplo, gestionarla desde phpmyadmin, introducir datos y verla en la web

ahora, si lo entendí todo bien, en lugar de consultar la base de datos desde la web, volcamos la base de datos mysql de forma periodica (por ejemplo si es un catálogo que se actualiza cada 15 días) a un fichero xml (1a tarea) y desde la web consultamos el fichero (se gana velocidad, no?) para consultar y presentar el fichero está xslt (2a tarea)

1a tarea: posiblemente phpmyadmin permita exportar la base de datos a un fichero xml, o incluso gestionarla directamente en un fichero xml

2a tarea: desde html, usando un fichero de presentación .xslt podemos presentar datos de un fichero xml enlazado al .xslt
ahora viene otro punto, cómo usar más de un fichero .xslt, si queremos presentar la base de datos .xml ordenada de distintas formas (desde .xml sólo se puede enlazar a un sólo fichero .xslt)

yo ahi no te puedo ayudar, no conozco ninguno, pero la tecnica es muy facil, lo mas dificil posiblemente a mi me parece es cargar los xmls en flash y tampoco es nada del otro mundo, si te animas lo podemos comentar aqui y te hecho una mano.

hay algún gestor de contenidos que lo lleve implementado o algo parecido?
o hay que currárselo desde cero

Estoy totalmente de acuerdo con dagi3d, de hecho si quieres poner en comunicacion flash y mysql, la manera mas comoda es generando xml con los datos de mysql, yo los genero al vuelo, pero eso es una cuestion de gustos, tambien hay que tener en cuenta la carga de consultas que tenga tu aplicacion, pero en general las dos tecnicas se suelen usar en paralelo y no una u otra,

ambas técnicas no son excluyentes, de hecho lo más común es usar las dos. desde un sistema de backend se gestionan los datos almacenados en una base de datos y luego se utiliza una representación de éstos en formato xml(ya sea generándolo al vuelo o en un fichero estático), normalmente para que otras aplicaciones puedan acceder a los datos utilizando así un formato que todos pueden entender facílmente.
pero no se trata de qué es lo que suelen preferir los clientes, si no lo de las necesidades de tu proyecto