Du mener, er der en database, der naturligt understøtter HTTP-protokollen? Nå, der er nogle. Du har MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ), og en NoSQL-database som CouchDB (http://couchdb.apache.org/ ). Du har det også i mere traditionelle rdbms-er som Oracle (Oracle Application Express er afhængig af en indbygget HTTP-server, også kendt som APEX-tjenesten http://www.oracle.com/technology/products/database/application_express/index.html ) og MS SQL (Service schema-objekt som http://msdn.microsoft. com/en-us/library/ms190332.aspx og XML-visninger, se http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Men egentlig - du bør stille spørgsmålstegn ved, om dette virkelig er så nyttigt.
Jeg mener, der vil altid være én komponent, der håndterer HTTP. Du har måske på fornemmelsen, at det er godt at tage webserver/php-laget ud, fordi du føler, det er ekstra, og sidder mellem appen og databasen. Men egentlig er de løsninger, jeg lige har nævnt, ikke så forskellige – de er tagget oven på det samme stykke software, men dataene skal stadig flyde gennem det ekstra lag.
Og du kan spekulere på, om det virkelig er fordelagtigt, hvis du har det hele i ét stykke:med en separat webserver kan du udskalere webserverlaget uafhængigt af databaseserveren. Eller du kan skalere databaselaget ud uafhængigt af webserverlaget. Hvis det hele er ét stykke software, kan du ikke.
Grundlæggende, ved at bygge http-serveren ind i databasen, belaster du db-serveren med en opgave, som bruger ressourcer, der kunne have været brugt til andre db-opgaver. Tænk nu på et almindeligt tilfælde, hvor du har betalt for en per-processor licens af din db. Kunne du virkelig tænke dig at bruge den licens på at få db til at håndtere HTTP-forespørgsler, når du kunne have gjort præcis det med en gratis webserver som apache? Selvom du bruger et gratis, blødt databaseprodukt, er databaseserveren i mange tilfælde en flaskehals. Vil du virkelig lægge flere opgaver på sin plade ved at bygge en HTTP-server ind i den?
Der er en anden grund til, at jeg synes, det ikke er så god en idé. Du nævnte XML som dataudvekslingsformat. Godt. Men hvad hvis du vil have JSON? Eller YAML? Eller måske almindelig CSV? Webserver-scriptsprog som PHP, ASP.NET, Perl og endda Java har alle meget gode biblioteker til at håndtere disse ting. Typiske databaselagrede proceduresprog gør det ikke. Selvfølgelig kan du tage det et skridt videre og sige, for helvede, hvorfor ikke bygge fx Java eller .NET ind i databasen, men det er at vende problemet på hovedet igen - databasens opgave er at gemme og hente data, og tage godt imod pleje af data, mens de opbevares. Behandling af data for at præsentere dem for en applikation er ikke en del af det. Hvis du gør det til en del af db's opgave at tage sig af det, fjerner du en vigtig kilde til fleksibilitet og skalerbarhed af systemet som helhed. Du føler måske, at det er mindre overhead, fordi der er en komponent mindre (dvs. webserver/scriptsprog) at tænke på, men i virkeligheden er den der stadig, den gemmer sig bare inde i din databasesoftware og suger de ressourcer op, der kunne have været brugt til lagring og hentning af data, parsing af forespørgsler osv.