Vuoi dire, esiste un database che supporta nativamente il protocollo HTTP? Bene, ce ne sono alcuni. Hai MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ) e un database NoSQL come CouchDB (http://couchdb.apache.org/ ). Lo hai anche in rdbms-es più tradizionali come Oracle (Oracle Application Express si basa su un server HTTP integrato, noto anche come servizio APEX http://www.oracle.com/technology/products/database/application_express/index.html ) e MS SQL (oggetto schema di servizio come http://msdn.microsoft. com/en-us/library/ms190332.aspx e viste XML, vedere http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Ma davvero - dovresti chiederti se questo è davvero così utile.
Voglio dire, ci sarà sempre un componente che gestisce HTTP. Potresti avere la sensazione che sia utile eliminare il livello webserver/php perché ritieni che sia extra e si trovi tra l'app e il database. Ma in realtà, le soluzioni che ho appena menzionato non sono così diverse:sono contrassegnate sopra lo stesso software, ma i dati devono comunque fluire attraverso quel livello aggiuntivo.
E puoi chiederti se sia davvero vantaggioso avere tutto in un unico pezzo:con un server web separato, puoi scalare il livello del server web indipendentemente dal server del database. Oppure puoi scalare il livello del database indipendentemente dal livello del server web. Se è tutto un software, non puoi.
Fondamentalmente, costruendo il server http nel database, stai sovraccaricando il server db con un'attività che consuma risorse che avrebbero potuto essere utilizzate per altre attività db. Ora pensa a un caso comune, in cui hai pagato una licenza per processore del tuo db. Ti piacerebbe davvero spendere quella licenza per far sì che il db gestisse le richieste HTTP, quando avresti potuto farlo esattamente con un server web gratuito come Apache? Anche se stai utilizzando un prodotto di database software gratuito, in molti casi il server di database è un collo di bottiglia. Vuoi davvero mettere più compiti sul piatto costruendo un server HTTP al suo interno?
C'è un altro motivo per cui penso che non sia una buona idea. Hai menzionato XML come formato per lo scambio di dati. Buono. Ma cosa succede se vuoi JSON? O YAML? O forse un semplice CSV? I linguaggi di scripting per server Web come PHP, ASP.NET, Perl e persino Java hanno tutti ottime librerie per gestire queste cose. I tipici linguaggi di stored procedure del database non lo fanno. Ovviamente, puoi fare un ulteriore passo avanti e dire, diavolo, perché non costruire ad esempio Java o .NET nel database, ma questo sta capovolgendo di nuovo il problema:il compito del database è archiviare e recuperare i dati, e prendere bene cura dei dati mentre sono archiviati. L'elaborazione dei dati per presentarli a un'applicazione non fa parte di questo. Se rendi parte del lavoro del db occuparsene, porti via un'importante fonte di flessibilità e scalabilità del sistema nel suo insieme. Potresti ritenere che sia meno sovraccarico perché c'è un componente in meno (es. server web/linguaggio di scripting) a cui pensare, ma in realtà è ancora lì, si nasconde solo all'interno del software del database e risucchia le risorse che avrebbero potuto essere utilizzate per memorizzazione e recupero di dati, analisi di query, ecc.
