acceder a la base de datos directamente del servidor a través de Ajax (sin PHP o algún otro medio)

Question

Con marcos de gran alcance como jQuery, parece ser posible construir toda una lógica de aplicación en el lado del cliente. Es muy similar a construir una aplicación cliente como un programa nativo.

Supongamos ahora que esta aplicación cliente necesita acceder a una base de datos remota. La solución habitual parece involucrar a las capas Ajax/PHP/MySQL.

Me parece que la capa de PHP ya no es necesaria; toda la lógica y la IU están a cargo de la aplicación del navegador.

La pregunta entonces es: ¿No existe una (esperemos robusta y segura) servidor de base de datos que simplemente adquiere una petición HTTP y devuelve un resultado XML? Este resultado puede ser fácilmente analizado, por ej. jQuery en el lado del cliente.

Parece que no puedo encontrar una base de datos o un marco en este sentido. ¿Algunas ideas?

Answer 1

¿Quiere decir que hay una base de datos que admita de forma nativa el protocolo HTTP? Bueno, hay algunos. Tiene MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/XRPC/) y bases de datos NoSQL como CouchDB (http://couchdb.apache.org/). También tiene en más de RDBMS-ES tradicionales como Oracle (Oracle Application Express se basa en un sistema incorporado en el servidor HTTP, también conocido como el servicio APEX http://www.oracle.com/technology/products/database/application_express/index.html) y MS SQL (Servicio esquema de objetos como http://msdn.microsoft.com/en-us/library/ms190332.aspx y XML vistas, consulte http://msdn.microsoft.com/en-us/library/aa286527.aspx)

Pero en realidad, debería preguntarse si esto es realmente tan útil.

Quiero decir, siempre va a haber un componente que maneje HTTP. Puede tener la sensación de que es bueno eliminar la capa de servidor web/php porque siente que es extra y se encuentra entre la aplicación y la base de datos. Pero, en realidad, las soluciones que acabo de mencionar no son tan diferentes: están etiquetadas sobre la misma pieza de software, pero los datos aún deben fluir a través de esa capa adicional.

Y usted puede preguntarse si esto es realmente beneficioso el tener todo en una sola pieza: con un servidor web independiente, puede escalar la capa de servidor web de forma independiente del servidor de base de datos. O puede escalar la capa de la base de datos independientemente de la capa del servidor web. Si se trata de una sola pieza de software, no se puede.

Básicamente, mediante la construcción de servidor http en la base de datos, usted es una carga para el servidor db con una tarea que consume recursos que podrían haber sido utilizados para otras tareas db.Ahora piense en un caso común, donde pagó por una licencia por procesador de su db. ¿Realmente le gustaría gastar esa licencia al hacer que el DB maneje las solicitudes HTTP, cuando podría haber hecho exactamente eso con un servidor web gratuito como apache? Incluso si está utilizando un producto de base de datos blando gratuito, en muchos casos el servidor de la base de datos es un cuello de botella. ¿Realmente quieres poner más tareas en su plato al construir un servidor HTTP en él?

Hay otra razón por la que creo que no es una buena idea. Mencionaste XML como formato de intercambio de datos. Bueno. Pero, ¿y si quieres JSON? O YAML? ¿O tal vez simple CSV? Los lenguajes de scripts de servidor web como PHP, ASP.NET, Perl e incluso Java tienen bibliotecas muy buenas para manejar estas cosas. Los lenguajes de procedimientos almacenados de bases de datos típicos no. Por supuesto, puede dar un paso más y decir, demonios, ¿por qué no compilar Java o .NET en la base de datos, pero eso está volviendo a poner el problema patas arriba? La tarea de la base de datos es almacenar y recuperar datos, y tomar buenas decisiones. cuidado de datos mientras está almacenado. Procesar datos para presentarlos a una aplicación no es parte de eso. Si hace que sea parte del trabajo del DB ocuparse de eso, le quita una importante fuente de flexibilidad y escalabilidad del sistema como un todo. Puede que sienta que hay menos gastos generales porque hay un componente menos (es decir, servidor web/lenguaje de scripting) en que pensar, pero en realidad sigue ahí, simplemente se esconde dentro del software de la base de datos y absorbe los recursos que podrían haberse utilizado para almacenar y recuperar datos, analizar consultas, etc.

Answer 2

Supongo que uno podría hacer eso, pero en lugar de PHP es más conveniente para la manipulación de conjuntos de resultados. Además, el enfoque tradicional proporciona un nivel adicional de seguridad para que las máquinas en la naturaleza no tengan acceso directo a la base de datos, y se pueden usar todos los controles de acceso y seguridad del servidor web habituales.

Answer 3

Bueno, la parte molesta será la autenticación.

Dado que el código se corrió por completo en el lado del cliente, el cliente conoce todos los detalles de autenticación para acceder al servidor de base de datos.

Esto es bastante ... err ... inseguro. Probablemente por eso no muchas personas han desarrollado un servidor de acceso directo ..

Si realmente desea mantener al mínimo las secuencias de comandos PHP/Server, haga un proxy PHP bastante robusto que escape correctamente todos los datos. Mantenga los detalles de la configuración en un archivo ini protegido por separado, o incluso en el archivo php.ini, y puede ignorar las secuencias de comandos del lado del servidor después de eso.