Você quer dizer, existe um banco de dados que suporte nativamente o protocolo HTTP? Bem, existem alguns. Você tem MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ) e bancos de dados NoSQL como o CouchDB (http://couchdb.apache.org/ ). Você também o tem em rdbms-es mais tradicionais como Oracle (Oracle Application Express depende de um servidor HTTP embutido, também conhecido como serviço APEX http://www.oracle.com/technology/products/database/application_express/index.html ) e MS SQL (objeto de esquema de serviço como http://msdn.microsoft. com/en-us/library/ms190332.aspx e exibições XML, consulte http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Mas realmente - você deve questionar se isso é realmente útil.
Quero dizer, sempre haverá um componente que lida com HTTP. Você pode ter a sensação de que é bom remover a camada webserver/php porque você acha que é extra e fica entre o aplicativo e o banco de dados. Mas, na verdade, as soluções que acabei de mencionar não são tão diferentes - elas são marcadas em cima do mesmo software, mas os dados ainda precisam fluir por essa camada extra.
E você pode se perguntar se isso é realmente benéfico ter tudo em uma única peça:com um servidor da Web separado, você pode dimensionar a camada do servidor da Web independentemente do servidor de banco de dados. Ou você pode dimensionar a camada de banco de dados independentemente da camada do servidor web. Se for tudo um software, você não pode.
Basicamente, ao construir o servidor http no banco de dados, você está sobrecarregando o servidor db com uma tarefa que consome recursos que poderiam ter sido usados para outras tarefas db. Agora pense em um caso comum, onde você pagou por uma licença por processador do seu banco de dados. Você realmente gostaria de gastar essa licença para que o banco de dados lidasse com solicitações HTTP, quando você poderia ter feito exatamente isso com um servidor da Web gratuito como o apache? Mesmo se você estiver usando um produto de banco de dados soft gratuito, em muitos casos o servidor de banco de dados é um gargalo. Você realmente quer colocar mais tarefas em seu prato construindo um servidor HTTP nele?
Há outra razão pela qual eu acho que não é uma boa ideia. Você mencionou XML como formato de troca de dados. Bom dia. Mas e se você quiser JSON? Ou YAML? Ou talvez CSV simples? Linguagens de script de servidor Web como PHP, ASP.NET, Perl e até mesmo Java têm bibliotecas muito boas para lidar com essas coisas. As linguagens típicas de procedimento armazenado de banco de dados não. Claro, você pode dar um passo adiante e dizer, diabos, por que não construir, digamos, Java ou .NET no banco de dados, mas isso está virando o problema de cabeça para baixo novamente - a tarefa do banco de dados é armazenar e recuperar dados e tirar boas cuidar dos dados enquanto estão armazenados. Processar dados para apresentá-los a um aplicativo não faz parte disso. Se você fizer parte do trabalho do banco de dados cuidar disso, você tira uma importante fonte de flexibilidade e escalabilidade do sistema como um todo. Você pode sentir que há menos sobrecarga porque há um componente a menos (ou seja, servidor da Web/linguagem de script) para pensar, mas na realidade, ainda está lá, apenas se esconde dentro do software de banco de dados e suga os recursos que poderiam ter sido usados para armazenar e recuperar dados, analisar consultas etc.
