Sie meinen, gibt es eine Datenbank, die das HTTP-Protokoll nativ unterstützt? Nun, es gibt einige. Sie haben MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ) und NoSQL-Datenbanken wie CouchDB (http://couchdb.apache.org/ ). ). Sie haben es auch in traditionelleren RDBMS wie Oracle (Oracle Application Express stützt sich auf einen integrierten HTTP-Server, auch bekannt als APEX-Dienst http://www.oracle.com/technology/products/database/application_express/index.html ) und MS SQL (Dienstschemaobjekt wie http://msdn.microsoft. com/en-us/library/ms190332.aspx und XML-Ansichten finden Sie unter http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Aber wirklich - man sollte sich fragen, ob das wirklich so nützlich ist.
Ich meine, es wird immer eine Komponente geben, die HTTP verarbeitet. Sie haben vielleicht das Gefühl, dass es gut ist, die Webserver/PHP-Schicht zu entfernen, weil Sie der Meinung sind, dass sie extra ist und zwischen der App und der Datenbank sitzt. Aber wirklich, die Lösungen, die ich gerade erwähnt habe, sind gar nicht so unterschiedlich – sie sind auf derselben Software getaggt, aber die Daten müssen immer noch durch diese zusätzliche Schicht fließen.
Und Sie können sich fragen, ob das wirklich von Vorteil ist, alles aus einem Guss zu haben:Mit einem separaten Webserver können Sie die Webserver-Schicht unabhängig vom Datenbankserver skalieren. Oder Sie können die Datenbankschicht unabhängig von der Webserverschicht skalieren. Wenn es sich um ein einziges Stück Software handelt, können Sie das nicht.
Wenn Sie den http-Server in die Datenbank einbauen, belasten Sie den DB-Server im Grunde mit einer Aufgabe, die Ressourcen verbraucht, die für andere DB-Aufgaben hätten verwendet werden können. Denken Sie nun an einen gewöhnlichen Fall, in dem Sie für eine Pro-Prozessor-Lizenz Ihrer Datenbank bezahlt haben. Möchten Sie diese Lizenz wirklich dafür ausgeben, dass die Datenbank HTTP-Anforderungen verarbeitet, wenn Sie genau das mit einem kostenlosen Webserver wie Apache hätten tun können? Selbst wenn Sie ein kostenloses Soft-Datenbankprodukt verwenden, ist der Datenbankserver in vielen Fällen ein Engpass. Wollen Sie ihm wirklich mehr Aufgaben auferlegen, indem Sie ihm einen HTTP-Server einbauen?
Es gibt noch einen weiteren Grund, warum ich denke, dass es keine so gute Idee ist. Sie haben XML als Datenaustauschformat erwähnt. Gut. Aber was, wenn Sie JSON wollen? Oder YAML? Oder vielleicht einfach CSV? Webserver-Skriptsprachen wie PHP, ASP.NET, Perl und sogar Java haben alle sehr gute Bibliotheken, um mit diesen Dingen umzugehen. Typische Sprachen für gespeicherte Datenbankprozeduren tun dies nicht. Natürlich können Sie noch einen Schritt weiter gehen und sagen, zum Teufel, warum bauen Sie nicht etwa Java oder .NET in die Datenbank ein, aber das stellt das Problem wieder auf den Kopf – die Aufgabe der Datenbank besteht darin, Daten zu speichern und abzurufen und gut zu machen Pflege der Daten, während sie gespeichert sind. Eine Verarbeitung der Daten zur Vorlage bei einer Bewerbung ist hiervon nicht umfasst. Wenn Sie es zu einem Teil der Aufgabe der DB machen, sich darum zu kümmern, nehmen Sie dem System als Ganzes eine wichtige Quelle der Flexibilität und Skalierbarkeit weg. Sie haben vielleicht das Gefühl, dass es weniger Overhead ist, weil es eine Komponente weniger gibt (dh Webserver/Skriptsprache), über die Sie nachdenken müssen, aber in Wirklichkeit ist sie immer noch da, sie versteckt sich nur in Ihrer Datenbanksoftware und saugt die Ressourcen auf, die hätten verwendet werden können Speichern und Abrufen von Daten, Analysieren von Abfragen usw.
