Du menar, finns det en databas som inbyggt stöder HTTP-protokollet? Tja, det finns några. Du har MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ), och en NoSQL-databaser som CouchDB (http://couchdb.apache.org/ ). Du har det också i mer traditionella rdbms-er som Oracle (Oracle Application Express är beroende av en inbyggd HTTP-server, alias APEX-tjänsten http://www.oracle.com/technology/products/database/application_express/index.html ) och MS SQL (Service schema-objekt som http://msdn.microsoft. com/en-us/library/ms190332.aspx och XML-vyer, se http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Men egentligen - du bör ifrågasätta om detta verkligen är så användbart.
Jag menar, det kommer alltid att finnas en komponent som hanterar HTTP. Du kanske har en känsla av att det är bra att ta ut webbserver/php-lagret för att du känner att det är extra, och sitter mellan appen och databasen. Men egentligen är lösningarna jag just nämnde inte så olika - de är taggade ovanpå samma mjukvara, men data måste fortfarande flöda genom det extra lagret.
Och du kan undra om det verkligen är fördelaktigt att ha allt i ett stycke:med en separat webbserver kan du skala ut webbserverlagret oberoende av databasservern. Eller så kan du skala ut databaslagret oberoende av webbserverlagret. Om allt är en mjukvara kan du inte.
I grund och botten, genom att bygga in http-servern i databasen, belastar du db-servern med en uppgift som förbrukar resurser som kunde ha använts för andra db-uppgifter. Tänk nu på ett vanligt fall, där du betalade för en per-processor licens för din db. Skulle du verkligen vilja spendera den licensen på att låta db hantera HTTP-förfrågningar, när du kunde ha gjort precis det med en gratis webbserver som apache? Även om du använder en gratis mjuk databasprodukt är databasservern i många fall en flaskhals. Vill du verkligen lägga fler uppgifter på sin platta genom att bygga in en HTTP-server i den?
Det finns en annan anledning till att jag tycker att det inte är en så bra idé. Du nämnde XML som datautbytesformat. Karamell. Men vad händer om du vill ha JSON? Eller YAML? Eller kanske vanlig CSV? Webserverskriptspråk som PHP, ASP.NET, Perl och till och med Java har alla mycket bra bibliotek för att hantera dessa saker. Typiska databaslagrade procedurspråk gör det inte. Naturligtvis kan man ta det ett steg längre och säga, fan, varför inte bygga in säg Java eller .NET i databasen, men det är att vända upp och ner på problemet igen - databasens uppgift är att lagra och hämta data, och ta bra ta hand om data medan den lagras. Bearbetning av data för att presentera dem för en applikation är inte en del av det. Om du gör det till en del av db:s jobb att ta hand om det tar du bort en viktig källa till flexibilitet och skalbarhet för systemet som helhet. Du kanske känner att det är mindre overhead eftersom det finns en komponent mindre (dvs. webbserver/skriptspråk) att tänka på, men i verkligheten finns den fortfarande kvar, den gömmer sig bara i din databasprogramvara och suger upp resurserna som kunde ha använts för lagra och hämta data, analysera frågor etc.