Vous voulez dire, existe-t-il une base de données qui supporte nativement le protocole HTTP ? Eh bien, il y en a. Vous avez MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/ XRPC/ ), et une base de données NoSQL comme CouchDB (http://couchdb.apache.org/ ). Vous l'avez également dans des rdbms plus traditionnels comme Oracle (Oracle Application Express s'appuie sur un serveur HTTP intégré, alias le service APEX http://www.oracle.com/technology/products/database/application_express/index.html ) et MS SQL (objet de schéma de service comme http://msdn.microsoft. com/en-us/library/ms190332.aspx et vues XML, voir http://msdn.microsoft.com/en- us/library/aa286527.aspx )
Mais vraiment - vous devriez vous demander si c'est vraiment utile.
Je veux dire, il y aura toujours un composant qui gère HTTP. Vous pouvez avoir l'impression qu'il est bon de supprimer la couche serveur Web/php parce que vous pensez qu'elle est supplémentaire et se situe entre l'application et la base de données. Mais vraiment, les solutions que je viens de mentionner ne sont pas si différentes - elles sont étiquetées au-dessus du même logiciel, mais les données doivent toujours traverser cette couche supplémentaire.
Et vous pouvez vous demander s'il est vraiment avantageux de tout avoir en un seul morceau :avec un serveur Web séparé, vous pouvez faire évoluer la couche de serveur Web indépendamment du serveur de base de données. Ou vous pouvez faire évoluer la couche de base de données indépendamment de la couche de serveur Web. S'il s'agit d'un seul logiciel, vous ne pouvez pas.
Fondamentalement, en construisant le serveur http dans la base de données, vous chargez le serveur de base de données avec une tâche qui consomme des ressources qui auraient pu être utilisées pour d'autres tâches de base de données. Pensez maintenant à un cas courant, où vous avez payé une licence par processeur de votre base de données. Aimeriez-vous vraiment dépenser cette licence pour que la base de données gère les requêtes HTTP, alors que vous auriez pu faire exactement cela avec un serveur Web gratuit comme apache ? Même si vous utilisez un produit de base de données logiciel gratuit, dans de nombreux cas, le serveur de base de données est un goulot d'étranglement. Voulez-vous vraiment mettre plus de tâches sur son assiette en y construisant un serveur HTTP ?
Il y a une autre raison pour laquelle je pense que ce n'est pas une si bonne idée. Vous avez mentionné XML comme format d'échange de données. Bravo. Mais que se passe-t-il si vous voulez du JSON ? Ou YAML ? Ou peut-être CSV simple ? Les langages de script de serveur Web comme PHP, ASP.NET, Perl et même Java ont tous de très bonnes bibliothèques pour gérer ces choses. Les langages de procédure stockée de base de données typiques ne le font pas. Bien sûr, vous pouvez aller un peu plus loin et dire, bon sang, pourquoi ne pas intégrer Java ou .NET dans la base de données, mais cela renverse à nouveau le problème - la tâche de la base de données est de stocker et de récupérer des données, et de prendre de bonnes soin des données pendant leur stockage. Le traitement des données pour les présenter à une application n'en fait pas partie. Si vous faites partie du travail de la base de données de s'occuper de cela, vous enlevez une source importante de flexibilité et d'évolutivité du système dans son ensemble. Vous pouvez avoir l'impression qu'il y a moins de surcharge parce qu'il y a un composant de moins (c'est-à-dire le serveur Web/langage de script) auquel il faut penser, mais en réalité, il est toujours là, il se cache juste à l'intérieur de votre logiciel de base de données et aspire les ressources qui auraient pu être utilisées pour stocker et récupérer des données, analyser des requêtes, etc.
