Applicazione lato server: Stored Procedure vs Query

[Lorenzo]

Scrivo perchè tormentato da un forte dubbio.
Sviluppando nei ritagli di tempo un'applicazione server che gestisce delle API,questa applicazione interroga una database.
Trattandosi di un'applicazione server,e come tale chiamata a gestire pool di varie connessioni,mi chiedevo se per far si che il server interagisca con il server DBMS si serva di normali queries oppure impieghi le Stored Procedures.
Se non ricordo male,le Stored Procedures hanno il vantaggio della cache,ovvero se un utente esegue una determinata query e l'utente successivo richiede gli stessi risultati della query precedente,non verrebbe eseguita una seconda volta la stessa query,ma il "fetch" dei risultati avverrebbe dallo stesso dataset.

Comunque ho una enorme confusione.
Nello sviluppo dei gestionali era scontato per me ricorrere alle semplici queries,specie per lo sviluppo dei clients o quando si trattava di un applicazione mono utenza con il DBMS nella stessa macchina.

Spero di essermi spiegato bene.

[DragoRosso]

Ciao.
Intanto il funzionamento specifico è determinato da quale DBMS usi.
Ad esempio se si parla di MS SQLServer, in realtà nessun risultato viene memorizzato ma viene usata la cache per mantenere i metadati in particolare di tabelle e indici.

Le stored procedures, hanno un processo particolare (cioè la compilazione) per cui ogni stored procedure usata rimane in memoria cache (la sua compilazione, non i risultati) per poter essere disponibile a future prossime richieste.
La cache è assolutamente gestita internamente ed è soggetta a una valutazione d'uso legata al carico, alle risorse di memoria o ad altri fattori, quindi non è assolutamente detto che ci sia sempre un vantaggio ad usare una o l'altra.
In genere si usano le stored procedure per attività che richiedono una certa complessità (come cicli o attivtà logiche varie) ed essendo "compilate" internamente hanno un vantaggio indubbio. Da notare che le stored procedure vengono compilate al primo utilizzo (e poi dopo essere state scaricate dalla cache).
Le query standard invece vengono "interpretate" ogni volta (non compilate) e quindi hanno un impatto nell'esecuzione.

Spero in poche righe di averti delucidato sulla cosa.

[Mimmo]

Ciao,
credo che per il tuoi server tu possa scegliere qualsiasi metodo: query o stored procedure o un mix di entrambe.
Oltre a tener conto di considerazioni come quelle già espresse da DragoRosso, valuta anche se hai convenienza a tenere la business logic della tua applicazione dentro il db (con le stored procedure) o lato codice del server (con le query). Io, per le esperienze che ho avuto, cerco di evitare gli approcci ibridi e, se la complessità sale, preferisco gestirla nel codice sorgente piuttosto che dentro il db. Però non c'è una regola universale, valuta come meglio credi. Come nota di colore: anni fa avevo visto una soluzione in ambiente manifatturiero sviluppata da una grossa società multinazionale fatta tutta con stored procedure su sql server e interfaccia utente costruita a botte di fogli excel. A me era venuta la pelle d'oca però in realtà riuscivano anche a venderla :-)

[DragoRosso]

Adesso che, ad esempio in PostgreSQL, si può inserire dentro un campo una stringa JSON e una query, e anche una stored procedure, può anche eseguire la richiesta sul contenuto del JSON direttamente (ossia come su fosse lui stesso un ulteriore campo del DB) ... bhè voglio proprio vedere chi è quello che usa le stored procedure in queste condizioni.

[Lorenzo]

Scusate il ritardo con cui rispondo.
Vi ringrazio per i vostri interventi,@DragoRosso e @Mimmo.
In passato ho studiato il PL/SQL di Oracle,ma non l'ho mai adoperato proprio perchè ho solidamente cre]duto che le Storde servissero solo per operazioni complesse di routine che richiedono un codice strutturato.
Di brutto c'è che non sono flessibili e non possono essere personalizzabili,però il trucchetto migliore mi sembra di impostarle in modo da non limitare loro i campi della tabella su cui operare.

@Mimmo sono d'accordo riguardo alla complessità delle operazioni,il codice Pascal sembra essere molto più potente e flessibile di qualsiasi linguaggio legato al DB.

Adesso che, ad esempio in PostgreSQL, si può inserire dentro un campo una stringa JSON e una query, e anche una stored procedure, può anche eseguire la richiesta sul contenuto del JSON direttamente (ossia come su fosse lui stesso un ulteriore campo del DB) ... bhè voglio proprio vedere chi è quello che usa le stored procedure in queste condizioni.

Interessante,anche se dovrei vedere come lavorare sulle Stored anche in Postgres.

Grazie ancora per i vs interventi.
.