Maksud Anda, apakah ada database yang secara native mendukung protokol HTTP? Nah, ada beberapa. Anda memiliki MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ), dan database NoSQL seperti CouchDB (http://couchdb.apache.org/ ). Anda juga memilikinya di rdbms-es yang lebih tradisional seperti Oracle (Oracle Application Express bergantung pada server HTTP bawaan, alias layanan APEX http://www.Oracle.com/technology/products/database/application_express/index.html ) dan MS SQL (Objek skema layanan seperti http://msdn.microsoft. com/en-us/library/ms190332.aspx dan tampilan XML, lihat http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Tapi sungguh - Anda harus mempertanyakan apakah ini benar-benar berguna.
Maksud saya, akan selalu ada satu komponen yang menangani HTTP. Anda mungkin merasa sebaiknya menghapus lapisan server web/php karena Anda merasa itu ekstra, dan berada di antara aplikasi dan database. Tapi sungguh, solusi yang baru saja saya sebutkan tidak terlalu berbeda - mereka ditandai di atas perangkat lunak yang sama, tetapi data masih harus mengalir melalui lapisan tambahan itu.
Dan Anda dapat bertanya-tanya apakah itu benar-benar bermanfaat karena memiliki semuanya dalam satu kesatuan:dengan server web terpisah, Anda dapat menskalakan lapisan server web secara terpisah dari server basis data. Atau Anda dapat menskalakan lapisan basis data secara terpisah dari lapisan server web. Jika itu semua satu bagian dari perangkat lunak, Anda tidak bisa.
Pada dasarnya, dengan membangun server http ke dalam database, Anda membebani server db dengan tugas yang menghabiskan sumber daya yang dapat digunakan untuk tugas db lainnya. Sekarang pikirkan tentang kasus umum, di mana Anda membayar untuk lisensi per-prosesor db Anda. Apakah Anda benar-benar ingin menghabiskan lisensi itu untuk membuat db menangani permintaan HTTP, ketika Anda bisa melakukannya dengan server web gratis seperti Apache? Bahkan jika Anda menggunakan produk database lunak gratis, dalam banyak kasus, server database menjadi hambatan. Apakah Anda benar-benar ingin menempatkan lebih banyak tugas di atasnya dengan membangun server HTTP ke dalamnya?
Ada alasan lain mengapa saya pikir itu bukan ide yang bagus. Anda menyebutkan XML sebagai format pertukaran data. Munafik. Tetapi bagaimana jika Anda menginginkan JSON? Atau YAML? Atau mungkin CSV biasa? Bahasa skrip server web seperti PHP, ASP.NET, Perl, dan bahkan Java semuanya memiliki pustaka yang sangat bagus untuk menangani hal-hal ini. Bahasa prosedur tersimpan database tipikal tidak. Tentu saja, Anda dapat mengambil langkah lebih jauh dan berkata, sial, mengapa tidak membangun katakanlah Java atau .NET ke dalam database, tetapi itu membalikkan masalah lagi - tugas database adalah menyimpan dan mengambil data, dan mengambil yang baik merawat data saat disimpan. Memproses data untuk menyajikannya ke aplikasi bukan bagian dari itu. Jika Anda menjadikannya bagian dari tugas db untuk mengurusnya, Anda mengambil sumber penting dari fleksibilitas dan skalabilitas sistem secara keseluruhan. Anda mungkin merasa ini lebih hemat karena ada satu komponen yang lebih sedikit (yaitu server web/bahasa scripting) untuk dipikirkan, tetapi pada kenyataannya, itu masih ada, hanya bersembunyi di dalam perangkat lunak database Anda, dan menyedot sumber daya yang dapat digunakan untuk menyimpan dan mengambil data, mengurai kueri, dll.
