Avec des cadres puissants tels que JQuery, il semble être possible de créer une logique de l'application entière sur le côté du client. Il est très analogue à la construction d'une application client comme programme indigène.
Supposons maintenant que cette application cliente a besoin d'accéder à une base de données distante. La solution habituelle semble impliquer les couches AJAX / PHP / MYSQL.
Il me semble que la couche PHP n'est plus nécessaire; Toute la logique et l'interface utilisateur sont prises en charge par l'application de navigateur.
La question est alors: ne devrait-il pas exister un serveur de base de données (espérons-le-chose et sécurisé) qui prend simplement une requête HTTP et renvoie un résultat XML? Ce résultat peut alors être facilement analysé par E.G. JQuery du côté du client.
Je n'arrive pas à trouver une base de données ou un cadre dans ce sens. Des idées?
3 Réponses :
Je suppose que l'on pourrait le faire, mais PHP est plutôt plus pratique pour la manipulation des ensembles de résultats. En outre, l'approche traditionnelle fournit un niveau de sécurité supplémentaire de manière à ce que les machines de la nature ne disposent pas d'un accès direct à la base de données, ainsi que tous les contrôles de sécurité et d'accès Webserver habituels peuvent être utilisés.
Eh bien, la partie agaçante va être authentification.
Parce que le code est complètement dirigé du côté du client, le client connaît ensuite tous les détails d'authentification pour accéder au serveur de base de données.
Ceci est plutôt .. err ... dangereux. Ce qui est probablement pourquoi pas beaucoup de gens ont développé un serveur d'accès direct ..
Si vous voulez vraiment garder le script php / serveur au minimum, faites un proxy PHP assez robuste que de s'échapper correctement toutes les données. Conservez les détails de la configuration dans un fichier INI protégé séparé, ou même le fichier php.ini, et vous pouvez toujours ignorer le script de côté serveur après cela.
J'ai lu et relire cette réponse et je continue de retourner non convaincu ... comparez-la à un client de messagerie et à un serveur de messagerie. Est-il intrinsèquement dangereux que le client de messagerie sait comment se connecter au mailserver et lire une boîte aux lettres? Pourquoi est-ce si différent d'un compte de base de données? Bien sûr, vous devez appliquer des privilèges appropriés sur votre compte de base de données - quelque chose que des applications Web ne fonctionnent généralement pas - mais cela ne change pas pour que vous puissiez parfaitement sécuriser un compte Databas comme vous le pouvez avec un compte de messagerie.
@Roland Vous pourrait pour que chaque utilisateur ait un compte de base de données. Mais ensuite, chaque utilisateur devrait également avoir sa propre base de données, à moins que vous ne puissiez définir des privilèges par table, auquel cas chaque utilisateur aurait besoin de sa propre table. (Semblable à une boîte aux lettres)
C'est mon point Chaca102. Dans tous les grands RDBMS-ES, vous pouvez accorder des privilèges par table. Vous pouvez même les accorde par colonne. Et cela ne s'arrête pas avec des tables et des colonnes, les routines et les vues stockées, etc. peuvent toutes être accordées individuellement. Et pour gérer que certains rôles de support RDBMS-ES, vous pouvez ainsi distribuer un ensemble de privilèges connexes. Si vous avez vraiment besoin de, vous pouvez même mettre en œuvre des privilèges au niveau de la ligne au niveau de la base de données (en utilisant des vues et / ou des procédures stockées).
Vous voulez dire, existe-t-il une base de données qui prend en charge de manière native le protocole HTTP? Eh bien, il y en a. Vous avez monédb / xquery ( http://monetdb.cwi.nl/xquerery/quicktour/xrpc/ ), et une base de données NOSQL comme Couchdb ( http://couchdb.apache.org/ ) . Vous l'avez également dans plus de RDBMS-ES plus traditionnels comme Oracle (Oracle Application Express s'appuie sur un serveur HTTP intégré, aka le service APEX http://www.oracle.com/technology/products/database/aplication_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/ Bibliothèque / AA286527.ASPX )
Mais vraiment - vous devriez vous demander si cela est vraiment utile.
Je veux dire, il y a toujours un composant qui gère HTTP. Vous avez peut-être le sentiment qu'il est bon de sortir la couche Web Web / PHP, car vous sentez qu'il est extra et est assis 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 sur le même logiciel, mais les données doivent encore passer à travers cette couche supplémentaire.
Et vous pouvez vous demander si cela est vraiment bénéfique, le fait de l'avoir tout en une seule pièce: avec un serveur Web séparé, vous pouvez évoluer la couche Web WebServer indépendamment du serveur de base de données. Ou vous pouvez accabler la couche de base de données indépendamment de la couche Web Webserver. Si c'est tout un logiciel, vous ne pouvez pas.
Fondamentalement, en construisant le serveur HTTP dans la base de données, vous n'utilisez le serveur DB avec une tâche qui consomme des ressources qui auraient pu être utilisées pour d'autres tâches de DB. Pensez maintenant à un cas commun, où vous avez payé une licence de processeur de votre DB. Voulez-vous vraiment dépenser cette licence d'avoir les demandes HTTP de la poignée de DB, lorsque 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 Soft 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 sa plaque en construisant un serveur http?
Il y a une autre raison pour laquelle je pense que ce n'est pas si bonne idée. Vous avez mentionné XML comme format Exchange de données. Goody. Mais si vous voulez JSON? Ou yaml? Ou peut-être un CSV simple? Des langages de script Web serveur comme PHP, ASP.NET, PERL et même Java ont tous de très bonnes bibliothèques pour faire face à ces choses. La base de données typique des langues de procédure stockées ne le font pas. Bien sûr, vous pouvez le faire un pas plus loin et dire, son enfer, pourquoi ne pas construire Dites Java ou .Net dans la base de données, mais cela met à nouveau le problème à l'envers - la tâche de la base de données consiste à stocker et à récupérer des données. soin des données pendant qu'il est stocké. Traitement des données pour le présenter à une application ne fait pas partie de cela. Si vous faites partie du travail de la DB pour m'occuper de cela, vous enlevez une source importante de flexibilité et d'évolutivité du système dans son ensemble. Vous pouvez penser que cela est moins frais, car il y a un composant moins (c'est-à-dire serveur Web / langue de script) à penser, mais en réalité, il est toujours là, il se cache simplement dans votre logiciel de base de données et craint les ressources qui auraient pu être utilisées pour Stockage et récupération de données, à analyser les requêtes, etc.