Masz na myśli, czy istnieje baza danych, która natywnie obsługuje protokół HTTP? Cóż, jest kilka. Masz MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ) oraz bazy danych NoSQL, takie jak CouchDB (http://couchdb.apache.org/ ). Masz go również w bardziej tradycyjnych rdbms-es, takich jak Oracle (Oracle Application Express opiera się na wbudowanym serwerze HTTP, znanym również jako usługa APEX http://www.oracle.com/technology/products/database/application_express/index.html ) i MS SQL (obiekt schematu usługi, taki jak http://msdn.microsoft. com/en-us/library/ms190332.aspx i widoki XML, patrz http://msdn.microsoft.com/en- us/biblioteka/aa286527.aspx )
Ale tak naprawdę - powinieneś zapytać, czy jest to naprawdę przydatne.
Mam na myśli, że zawsze będzie jeden komponent, który obsługuje HTTP. Możesz mieć wrażenie, że dobrze jest usunąć warstwę serwera WWW/php, ponieważ uważasz, że jest ona dodatkowa i znajduje się pomiędzy aplikacją a bazą danych. Ale tak naprawdę rozwiązania, o których właśnie wspomniałem, nie różnią się aż tak bardzo – są oznaczone na wierzchu tego samego oprogramowania, ale dane nadal muszą przepływać przez tę dodatkową warstwę.
I można się zastanawiać, czy posiadanie tego wszystkiego w jednym kawałku jest naprawdę korzystne:z osobnym serwerem sieciowym można skalować warstwę serwera sieciowego niezależnie od serwera bazy danych. Możesz też skalować warstwę bazy danych niezależnie od warstwy serwera WWW. Jeśli to wszystko jest jednym oprogramowaniem, nie możesz.
Zasadniczo, wbudowując serwer http w bazę danych, obciążasz serwer db zadaniem, które zużywa zasoby, które mogłyby zostać wykorzystane do innych zadań bazy danych. Teraz pomyśl o typowym przypadku, w którym zapłaciłeś za licencję na procesor swojej bazy danych. Czy naprawdę chciałbyś wydać tę licencję na obsługę żądań HTTP przez bazę danych, podczas gdy mógłbyś to zrobić z darmowym serwerem WWW, takim jak Apache? Nawet jeśli korzystasz z bezpłatnego miękkiego produktu bazodanowego, w wielu przypadkach serwer bazy danych stanowi wąskie gardło. Czy naprawdę chcesz umieścić więcej zadań na talerzu, wbudowując w to serwer HTTP?
Jest jeszcze jeden powód, dla którego uważam, że to nie jest dobry pomysł. Wspomniałeś XML jako format wymiany danych. Cukierek. Ale co, jeśli chcesz JSON? Lub YAML? A może zwykły CSV? Języki skryptowe serwera WWW, takie jak PHP, ASP.NET, Perl, a nawet Java, mają bardzo dobre biblioteki do radzenia sobie z tymi rzeczami. Typowe języki procedur składowanych bazy danych nie. Oczywiście można pójść o krok dalej i powiedzieć, do diabła, dlaczego nie wbudować powiedzmy Java lub .NET do bazy danych, ale to odwraca problem z powrotem do góry nogami - zadaniem bazy danych jest przechowywanie i pobieranie danych oraz dobre dbać o dane podczas ich przechowywania. Przetwarzanie danych w celu przedstawienia ich aplikacji nie jest częścią tego. Jeśli dbanie o to jest częścią pracy bazy danych, zabierasz ważne źródło elastyczności i skalowalności systemu jako całości. Możesz czuć, że jest to mniej narzutowe, ponieważ jest jeden komponent mniej (tj. serwer WWW/język skryptowy), o którym musisz myśleć, ale w rzeczywistości nadal tam jest, po prostu ukrywa się w oprogramowaniu bazy danych i wysysa zasoby, które mogły zostać użyte do przechowywanie i pobieranie danych, parsowanie zapytań itp.
