つまり、HTTPプロトコルをネイティブにサポートするデータベースはありますか？さて、いくつかあります。 MonetDB / XQuery（http://monetdb.cwi.nl/XQuery/QuickTour/がありますXRPC / ）、およびCouchDB（ http://couchdb.apache.org/ ）などのNoSQLデータベース ）。 Oracleなどの従来のrdbms-esにもあります（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を処理するコンポーネントは常に1つあります。 webserver / phpレイヤーは余分であり、アプリとデータベースの間にあると感じるので、それを削除するのが良いと感じるかもしれません。しかし実際には、今述べたソリューションはそれほど違いはありません。同じソフトウェアの上にタグが付けられていますが、データはその余分なレイヤーを通過する必要があります。
そして、それが本当に有益であるかどうか疑問に思うかもしれません。すべてを1つにまとめることで、データベースサーバーとは独立してWebサーバーレイヤーをスケールアウトできます。または、Webサーバーレイヤーとは別にデータベースレイヤーをスケールアウトすることもできます。それがすべて1つのソフトウェアである場合、それはできません。
基本的に、httpサーバーをデータベースに組み込むことにより、他のdbタスクに使用された可能性のあるリソースを消費するタスクをdbサーバーに負担させることになります。ここで、データベースのプロセッサごとのライセンスの料金を支払った一般的なケースについて考えてみましょう。 apacheのような無料のウェブサーバーでまさにそれを行うことができたのに、dbにHTTPリクエストを処理させることにそのライセンスを本当に費やしたいですか？無料のソフトデータベース製品を使用している場合でも、多くの場合、データベースサーバーがボトルネックになっています。 HTTPサーバーを構築することで、より多くのタスクをプレートに配置したいですか？
それがそれほど良い考えではないと私が思うもう一つの理由があります。データ交換フォーマットとしてXMLについて言及されました。グッディ。しかし、JSONが必要な場合はどうでしょうか？またはYAML？それとも単純なCSVですか？ PHP、ASP.NET、Perl、さらにはJavaなどのWebサーバースクリプト言語にはすべて、これらのことを処理するための非常に優れたライブラリがあります。一般的なデータベースのストアドプロシージャ言語はそうではありません。もちろん、さらに一歩進んで、Javaや.NETをデータベースに組み込んでみませんか？しかし、それは問題を再び逆さまにしています-データベースのタスクは、データを保存および取得し、うまくいくことです保存中のデータの管理。データを処理してアプリケーションに提示することは、その一部ではありません。それを処理することをデータベースの仕事の一部にすると、システム全体の柔軟性とスケーラビリティの重要な源泉を奪うことになります。考えるコンポーネントが1つ少ないため（つまり、Webサーバー/スクリプト言語）、オーバーヘッドが少ないと感じるかもしれませんが、実際には、それはまだ存在し、データベースソフトウェア内に隠れて、使用された可能性のあるリソースを吸収します。データの保存と取得、クエリの解析など。