He recuperado un proyecto de rebote y estoy en medio de unas dudas y quería que me echarais una mano.
Por una parte tengo un proveedor que está realizando una parte del desarrollo con una base de datos en MySQL y un servidor de aplicaciones JBOSS. Han desarrollado una serie de consultas XML para poder tener acceso a todos los datos.
Por otra parte otro proveedor está desarrollando una web en php recuperando los datos con las consultas xml.
1. ¿Por qué 2 proveedores? Porque está establecido así y no lo puedo cambiar.
2. La página que más consultas necesita son 10 consultas XML. (pero con pocos datos), la mayoría entre 2 y 3.
3. El proveedor de la parte web me dice que no quiere usar más de una consulta por página porque ralentizaría mucho la web y que no es profesional hacerlo de otra forma.
4. Ciertas páginas necesitan algún cálculo sobre los datos. Ejemplo un cálculo de la media de los datos recibidos.
5. De cara al futuro de este proyecto me interesa tener unas consultas genéricas ya que varios clientes querrán usar estos datos de forma distinta y será muy complicado de gestionar/mantener/crear consultas específicas para cada página y cliente.
6. No quiero usar un fichero de datos XML generado previamente para la lectura en local porque sería necesario más de 5000 ficheros diarios y conservarlos durante años, (problema de espacio)
Dudas que tengo después de haber escuchado los 2 proveedores:
1. ¿Realmente existe una diferencia en tiempo de recuperar varias consultas y realizar algún cálculo en php en vez de una consulta xml única que realice los cálculos y me mande los resultados?
2. ¿Es más seguro una recuperación de datos mediante XML o directamente de la base de datos?
3. ¿Cuál sería la mejor solución técnica con el pequeño resumen que os he expuesto?
Muchas gracias de antemano
Hola,
Vamos con tus tres preguntas, porque las tres están relacionadas:
1. ¿Hay diferencia real entre varias consultas pequeñas + cálculo en PHP, frente a una única consulta XML que ya devuelva el resultado calculado? Sí, y no es un matiz pequeño. Cada consulta XML es una petición HTTP independiente: conexión, negociación, ida y vuelta por la red, procesamiento en el servidor JBOSS, respuesta. Aunque cada consulta individual sea rápida, si tu página hace hasta 10 de esas peticiones secuenciales, el tiempo total no es «el tiempo de la consulta más lenta», es la suma de las 10 idas y vueltas. Una única consulta que ya devuelva el resultado final (con los cálculos hechos en el servidor, cerca de los datos) casi siempre es más rápida, a veces de forma muy notable si la red entre los dos proveedores no es especialmente rápida.
2. ¿Es más seguro el XML o el acceso directo a base de datos? Ninguno de los dos es «más seguro» solo por elegirlo, la seguridad depende de cómo se implemente cada uno (autenticación, HTTPS, validación de qué puede pedir cada cliente). Pero hay un matiz operativo importante: si el proveedor de la web PHP accediera directamente a la base de datos del otro proveedor, eso significa compartir credenciales de base de datos entre dos equipos distintos, lo cual es difícil de auditar y rotar, y si la web PHP tiene algún fallo de seguridad, el atacante llega directamente a la base de datos completa. Con una capa de API XML de por medio, el proveedor de datos controla exactamente qué se expone y qué no, sin dar acceso directo a su base de datos a un tercero. En ese sentido, mantener la capa XML es la decisión arquitectónicamente más sana, aunque el motivo real no sea «el XML es más seguro» en abstracto.
3. ¿Cuál sería la mejor solución técnica? Le pediría al proveedor de JBOSS que cree una única consulta XML consolidada por caso de uso de página, que internamente haga los JOIN/cálculos que hoy hace PHP después de recibir los 10 resultados por separado, y devuelva ya el resultado final listo para pintar. Esto resuelve a la vez el problema de rendimiento (una sola ida y vuelta en vez de diez) y mantiene la separación de responsabilidades que ya tenéis (cada proveedor gestiona su parte, sin acceso directo cruzado a bases de datos ajenas).
David Carrero