Искате да кажете, има ли база данни, която изначално поддържа HTTP протокола? Е, има и такива. Имате MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ) и NoSQL бази данни като CouchDB (http://couchdb.apache.org/ ). Имате го и в по-традиционни rdbms-и като Oracle (Oracle Application Express разчита на вграден HTTP сървър, известен още като услугата 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? Или YAML? Или може би обикновен CSV? Скриптовите езици на уеб сървъри като PHP, ASP.NET, Perl и дори Java имат много добри библиотеки за справяне с тези неща. Типичните езици за съхранявани процедури на база данни не го правят. Разбира се, можете да направите още една стъпка напред и да кажете, по дяволите, защо не вградите, например, Java или .NET в базата данни, но това отново обръща проблема с главата надолу - задачата на базата данни е да съхранява и извлича данни и да приема добре грижа за данните, докато се съхраняват. Обработката на данни за представянето им в приложение не е част от това. Ако го направите част от работата на db да се грижи за това, вие отнемате важен източник на гъвкавост и мащабируемост на системата като цяло. Може да почувствате, че е по-малко излишно, защото има един компонент по-малко (т.е. уеб сървър/скриптов език), за който да мислите, но в действителност той все още е там, просто се крие в софтуера на вашата база данни и изсмуква ресурсите, които биха могли да бъдат използвани за съхраняване и извличане на данни, разбор на заявки и др.
