Je bedoelt, is er een database die native het HTTP-protocol ondersteunt? Nou, er zijn er een paar. Je hebt MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ), en een NoSQL-database zoals CouchDB (http://couchdb.apache.org/ ). Je hebt het ook in meer traditionele rdbms-es zoals Oracle (Oracle Application Express vertrouwt op een ingebouwde HTTP-server, ook bekend als de APEX-service http://www.oracle.com/technology/products/database/application_express/index.html ) en MS SQL (Serviceschema-object zoals http://msdn.microsoft. com/en-us/library/ms190332.aspx en XML-weergaven, zie http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Maar echt - je moet je afvragen of dit echt zo handig is.
Ik bedoel, er zal altijd één component zijn die HTTP afhandelt. Je hebt misschien het gevoel dat het goed is om de webserver/php-laag eruit te halen omdat je denkt dat het extra is en tussen de app en de database zit. Maar echt, de oplossingen die ik zojuist noemde zijn niet zo verschillend - ze zijn getagd bovenop hetzelfde stuk software, maar de gegevens moeten nog steeds door die extra laag stromen.
En je kunt je afvragen of dat echt voordelig is als je alles in één stuk hebt:met een aparte webserver kun je de webserverlaag onafhankelijk van de databaseserver uitschalen. Of u kunt de databaselaag onafhankelijk van de webserverlaag uitschalen. Als het allemaal één stuk software is, kan dat niet.
Kortom, door de http-server in de database in te bouwen, belast u de db-server met een taak die bronnen verbruikt die voor andere db-taken hadden kunnen worden gebruikt. Denk nu aan een veelvoorkomend geval, waarbij u betaalde voor een licentie per processor van uw db. Zou je die licentie echt willen besteden om de db HTTP-verzoeken te laten afhandelen, terwijl je precies dat had kunnen doen met een gratis webserver zoals apache? Zelfs als u een gratis soft databaseproduct gebruikt, is de databaseserver in veel gevallen een knelpunt. Wil je echt meer taken op het bord leggen door er een HTTP-server in te bouwen?
Er is nog een reden waarom ik het niet zo'n goed idee vind. U noemde XML als formaat voor gegevensuitwisseling. Goed. Maar wat als je JSON wilt? Of YAM? Of misschien gewoon CSV? Webserver-scripttalen zoals PHP, ASP.NET, Perl en zelfs Java hebben allemaal zeer goede bibliotheken om met deze dingen om te gaan. Typische talen voor opgeslagen procedures in databases doen dat niet. Natuurlijk kun je nog een stap verder gaan en zeggen, verdorie, waarom zou je Java of .NET niet in de database bouwen, maar dat zet het probleem weer op zijn kop - de taak van de database is om gegevens op te slaan en op te halen, en goed zorg voor gegevens terwijl deze zijn opgeslagen. Het verwerken van gegevens om deze te presenteren aan een applicatie hoort daar niet bij. Als u het tot de taak van de db maakt om daarvoor te zorgen, neemt u een belangrijke bron van flexibiliteit en schaalbaarheid van het systeem als geheel weg. Je hebt misschien het gevoel dat het minder overhead is omdat er één component minder is (dwz webserver/scriptingtaal) om over na te denken, maar in werkelijkheid is het er nog steeds, het verbergt zich gewoon in je databasesoftware en zuigt de bronnen op die hadden kunnen worden gebruikt voor het opslaan en ophalen van gegevens, het parseren van query's enz.