¿Quieres decir, hay una base de datos que admita de forma nativa el protocolo HTTP? Bueno, hay algunos. Tienes MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ) y bases de datos NoSQL como CouchDB (http://couchdb.apache.org/ ). También lo tiene en rdbms-es más tradicionales como Oracle (Oracle Application Express se basa en un servidor HTTP integrado, también conocido como el servicio APEX http://www.oracle.com/technology/products/database/application_express/index.html ) y MS SQL (objeto de esquema de servicio como http://msdn.microsoft. com/en-us/library/ms190332.aspx y vistas XML, consulte http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Pero realmente, deberías preguntarte si esto es realmente tan útil.
Quiero decir, siempre habrá un componente que maneje HTTP. Puede tener la sensación de que es bueno sacar la capa del 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 encima de la misma pieza de software, pero los datos aún tienen que fluir a través de esa capa adicional.
Y puede preguntarse si es realmente beneficioso tenerlo todo en una sola pieza:con un servidor web separado, puede escalar la capa del servidor web independientemente del servidor de la base de datos. O puede escalar horizontalmente 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, al incorporar el servidor http en la base de datos, está cargando al servidor de base de datos con una tarea que consume recursos que podrían haberse utilizado para otras tareas de base de datos. Ahora piense en un caso común, en el que pagó por una licencia por procesador de su db. ¿Realmente le gustaría gastar esa licencia para que la base de datos 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 quiere 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. Usted mencionó XML como formato de intercambio de datos. Bueno. Pero, ¿y si quieres JSON? ¿O YAML? ¿O tal vez simple CSV? Los lenguajes de secuencias de comandos del servidor web como PHP, ASP.NET, Perl e incluso Java tienen bibliotecas muy buenas para manejar estas cosas. Los lenguajes típicos de procedimientos almacenados de bases de datos no lo hacen. Por supuesto, puede ir un paso más allá y decir:diablos, ¿por qué no incorporar, por ejemplo, Java o .NET en la base de datos? cuidado de los datos mientras están almacenados. El procesamiento de datos para presentarlos a una aplicación no es parte de eso. Si hace que sea parte del trabajo de la base de datos encargarse de eso, le quitará una importante fuente de flexibilidad y escalabilidad al sistema en su conjunto. Puede sentir que es menos sobrecarga porque hay un componente menos (es decir, servidor web/lenguaje de secuencias de comandos) en el que pensar, pero en realidad, todavía está allí, simplemente se esconde dentro del software de su base de datos y absorbe los recursos que podrían haberse utilizado para almacenar y recuperar datos, analizar consultas, etc.
