Accesso diretto database del server tramite Ajax (senza PHP o qualche altro intermedio)

Question

Con quadri potenti come jQuery, sembra essere possibile costruire un intero logica app sul lato client. È molto simile alla creazione di un'app client come un programma nativo.

Ora supponiamo che questa app client debba accedere a un database remoto. La solita soluzione sembra coinvolgere gli strati Ajax/PHP/MySQL.

Mi sembra che lo strato PHP non sia più necessario; tutta la logica e l'interfaccia utente sono gestite dall'app browser.

La domanda allora è: Non dovrebbe esistere un (si spera robusto e sicuro) server di database che prende semplicemente in una richiesta HTTP, e restituisce un risultato XML? Questo risultato può quindi essere facilmente analizzato, ad es. jQuery sul lato client.

Non riesco a trovare un database o un framework su queste linee. Qualche idea?

Answer 1

Vuoi dire, c'è un database che supporta in modo nativo il protocollo HTTP? Bene, ci sono alcuni. Hai MonetDB/XQuery (http://monetdb.cwi.nl/XQuery/QuickTour/XRPC/) e un database NoSQL come CouchDB (http://couchdb.apache.org/). Hai anche nelle più tradizionali RDBMS-es come Oracle (Oracle Application Express si basa su un built-in server HTTP, alias il servizio APEX http://www.oracle.com/technology/products/database/application_express/index.html) e MS SQL (servizio oggetto dello schema come http://msdn.microsoft.com/en-us/library/ms190332.aspx e XML viste, vedere http://msdn.microsoft.com/en-us/library/aa286527.aspx)

Ma davvero - dovresti chiedertelo se è davvero così utile.

Voglio dire, ci sta andando sempre essere una componente che gestisce HTTP. Potresti avere la sensazione che sia bello togliere il livello webserver/php perché ritieni che sia extra e si trova tra l'app e il database. Ma in realtà le soluzioni che ho appena menzionato non sono poi così diverse: sono etichettate in cima allo stesso software, ma i dati devono ancora scorrere attraverso quel livello in più.

E ci si può chiedere se sia davvero vantaggioso avere tutto in un unico pezzo: con un server web separato, è possibile ridimensionare il livello del server web indipendentemente dal server del database. Oppure puoi ridimensionare il livello del database indipendentemente dal livello del server web. Se è tutto un pezzo di software, non puoi.

Fondamentalmente, creando il server http nel database, si carica il server db con un'attività che consuma risorse che potrebbero essere state utilizzate per altre attività di db.Ora pensa a un caso comune, in cui hai pagato una licenza per processore del tuo db. Ti piacerebbe davvero spendere quella licenza per avere il db gestire le richieste HTTP, quando avresti potuto farlo esattamente con un server web gratuito come Apache? Anche se si utilizza un prodotto di database soft gratuito, in molti casi il server di database è un collo di bottiglia. Vuoi veramente mettere più compiti sulla sua piattaforma costruendo un server HTTP?

C'è un altro motivo per cui penso che non sia una buona idea. Hai citato XML come formato di scambio di dati. Goody. Ma cosa succede se vuoi JSON? O YAML? O forse semplicemente CSV? I linguaggi di scripting di Webserver come PHP, ASP.NET, Perl e anche Java hanno tutti ottime librerie per gestire queste cose. I tipici linguaggi di stored procedure del database non lo sono. Naturalmente, puoi fare un ulteriore passo avanti e dire, diavolo, perché non costruire dire Java o .NET nel database, ma questo sta capovolgendo il problema - il compito del database è quello di archiviare e recuperare i dati, e prendere bene cura dei dati mentre sono archiviati. L'elaborazione dei dati per presentarla a un'applicazione non fa parte di questo. Se si fa parte del lavoro di db per prendersi cura di questo, si prende una fonte importante di flessibilità e scalabilità del sistema nel suo complesso. Potresti sentirti meno sovraccarico perché c'è un componente in meno (ad es. Il webserver/linguaggio di scripting) a cui pensare, ma in realtà è ancora lì, si nasconde semplicemente all'interno del tuo software di database e risucchia le risorse che avrebbero potuto essere utilizzate per memorizzazione e recupero di dati, analisi di query, ecc.

Answer 2

Suppongo si possa farlo, ma PHP è molto più conveniente per la manipolazione di set di risultati. Inoltre, l'approccio tradizionale fornisce un ulteriore livello di sicurezza in modo che le macchine in natura non abbiano accesso diretto al database e che tutti i normali controlli di sicurezza e accesso al server web possano essere utilizzati.

Answer 3

Bene, la parte fastidiosa sarà l'autenticazione.

Dato che il codice è stato eseguito completamente sul lato client, il cliente sa poi tutti i dettagli di autenticazione per accedere al server di database.

Questo è piuttosto .. err ... non sicuro. Il che è probabilmente il motivo per cui non molte persone hanno sviluppato un server ad accesso diretto ..

Se davvero si vuole mantenere lo scripting PHP/Server-Side al minimo, fare un abbastanza robusto delega PHP che sfugge correttamente tutti i dati. Conserva i dettagli di configurazione in un file ini protetto separato, o anche nel file php.ini, e puoi tranquillamente ignorare lo scripting sul lato server.