Вы имеете в виду, есть ли база данных, которая изначально поддерживает протокол HTTP? Ну, есть некоторые. У вас есть MonetDB / XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/XRPC/), и базы данных NoSQL, такие как CouchDB (http://couchdb.apache.org/).). Вы также можете использовать его в более традиционных rdbms-системах, таких как Oracle (Oracle Application Express использует встроенный HTTP-сервер, aka служба APEX http://www.oracle.com/technology/products/database/application_express/index.html) и MS SQL (объект схемы службы, такой как http://msdn.microsoft.com/en-us/library/ms190332.aspx и представления XML, см. http://msdn.microsoft.com/en-us/library/aa286527.aspx)
Но на самом деле - вы должны спросить, действительно ли это так полезно.
Я имею в виду, что всегда будет один компонент, который обрабатывает HTTP. У вас может возникнуть ощущение, что лучше удалить слой веб-сервера / php, потому что вы чувствуете, что он лишний и находится между приложением и базой данных. Но на самом деле решения, которые я только что упомянул, не так уж и отличаются - они помечены поверх одного и того же программного обеспечения, но данные все равно должны проходить через этот дополнительный слой.
И вы можете задаться вопросом, действительно ли это выгодно, если все это будет в одном месте: с отдельным веб-сервером вы можете масштабировать уровень веб-сервера независимо от сервера базы данных. Или вы можете масштабировать слой базы данных независимо от уровня веб-сервера. Если это все одна часть программного обеспечения, вы не можете.
По сути, встроив http-сервер в базу данных, вы обременяете сервер db задачей, которая потребляет ресурсы, которые могли бы быть использованы для других задач db. Теперь подумайте о распространенном случае, когда вы платили за лицензию на процессор вашего db. Вы действительно хотели бы потратить эту лицензию на то, чтобы db обрабатывал HTTP-запросы, когда вы могли бы сделать именно это с помощью бесплатного веб-сервера, такого как apache? Даже если вы используете бесплатный программный продукт базы данных, во многих случаях сервер базы данных является узким местом. Вы действительно хотите поставить больше задач на свой планшет, встроив в него HTTP-сервер?
Есть еще одна причина, почему я думаю, что это не очень хорошая идея. Вы упомянули XML как формат обмена данными. Гуди. Но что, если вы хотите JSON? Или ЯМЛ? Или, может быть, простой CSV? Языки сценариев веб-сервера, такие как PHP, ASP.NET, Perl и даже Java, имеют очень хорошие библиотеки для решения этих задач. Типичные базы данных хранимых процедур языков нет. Конечно, вы можете сделать еще один шаг вперед и сказать, черт возьми, почему бы не встроить, скажем, Java или .NET в базу данных, но это переворачивает проблему с ног на голову - задача базы данных - хранить и извлекать данные, а также забота о данных, пока они хранятся. Обработка данных для представления их в приложение не является частью этого. Если вы сделаете это частью работы БД, чтобы позаботиться об этом, вы заберете важный источник гибкости и масштабируемости системы в целом. Вы можете почувствовать, что это меньше затрат, потому что есть на один компонент меньше (т. Е. Веб-сервер / язык сценариев) для размышлений, но в действительности он все еще здесь, он просто прячется в программном обеспечении вашей базы данных и высасывает ресурсы, которые могли быть использованы для хранение и извлечение данных, анализ запросов и т. д.