Newsgroup: it.comp.lang.delphi
Titolo: Firebird-dbexpress: meglio SQL nel codice o nelle stored procedure ?

Buongiorno a tutti,
 
nel weekend pasquale mi sono posto dei dubbi sull'opportunità di usare sempre delle stored procedures, sempre il codice SQL direttamente nell'applicazione delphi, oppure situazioni miste.
 
Di solito uso dei TSimpleDataset (non scannatemi perchè mi ci trovo bene), imposto la SELECT nel CommandText ed il resto vien da se (insert, edit, delete, applyUpdate).
Eccezionalmente su tabelle molto popolate faccio la select su View di Firebird e riempio il solito TSimpleDataset; per le insert-update passo invece i valori a delle Procedures di Firebird.
 
chiedo:
1) è corretto l'approccio di spalmare il carico di lavoro tra pc e server?
2) considerata l'attuale evoluzione tecnologica ( server multi core, lan /1000, processori 64 bit, ecc, quale sarebbe la pratica da preferire?
 
--
Giovanni

 2) considerata l'attuale evoluzione tecnologica
 
Non esiste una "via giusta"...magari ci fosse.
Dipende dal tipo di applicazione, dal contesto, dalle tecnolgie coinvolte, dal budget, dalla fretta....
 
La cosa REALMENTE IMPORTANTE e' scegliere con criterio e cognizione di causa, evitando la fiducia a scatola chiusa verso i "Profeti" di turno che non saranno poi con te "by night" a sistemare  casini per i quali il cliente minaccia di portarti in tribunale per danni.
 
Si valuta, si prova, si fanno test, ci si arrampica sugli specchi pensando a quello che potrebbe servirci di una particolare tecnologia per poterla provare e capire se funziona e conoscerne vantaggi, svantaggi e punti deboli.
 
 
A.

 2) considerata l'attuale evoluzione tecnologica ( server multi core, lan /1000, processori 64 bit, ecc, quale sarebbe la pratica da preferire?
 
La pratica da preferire non e` tanto legata all'evoluzione delle macchine, quanto all'evoluzione dei metodi di produzione del software. Oggi c'e` una grossa spinta verso continuous integration/delivery, con strategie di sviluppo/testing (xUnit, TDD/ATDD) dalle quali non si puo` piu` prescindere. Questo significa cercare di scrivere codice il piu` possibile utilizzando una tecnologia che si presti bene ad essere testata. I vari SQL implementati dai piu` comuni RDBMS sono notoriamente linguaggi procedurali, in cui logica e` difficile da testare. Io ho "unit-testato" persino codice PL/SQL, pero`, per cui si puo` fare, ma forse e` meglio avere la business logic implementata da un application server.

 La cosa REALMENTE IMPORTANTE e' scegliere con criterio e cognizione di causa, evitando la fiducia a scatola chiusa verso i "Profeti" di turno che non saranno poi con te "by night" a sistemare  casini per i quali il cliente minaccia di portarti in tribunale per danni.
 
Per fortuna esistono tecniche, oggi, che consentono di scrivere il software in maniera tale da rendere molto difficile che il cliente ti trascini in tribunale. Il problema e` che non tutti le adottano.

 Il problema e` che non tutti le adottano.
 
Quoto.
 
A.

 Se si parla di TECNOLOGIE, non sono completamente d'accordo, semplicemente xche molte cose "corrette" finiscono per diventare "non corrette" in tempi a volte molto brevi.
 
A cosa ti riferisci, nello specifico? Un esempio?

> A cosa ti riferisci, nello specifico? Un esempio?
 
XML e WebService rispetto a Json/REST
Asp.Net webform rispetto alle varie versioni di MVC di vs
Remoting rispetto a WCF
 
A.
 
 
 

 XML e WebService rispetto a Json/REST
 
Ahemm... a me sembra tu faccia un pochino di confusione :)
REST e` un pattern architetturale e si possono scrivere web services RESTful, basati sia su JSON che su XML. 
 
Idem per MVC e 
ASP.NET
. 
 
In ogni caso, e` vero che le tecnologie variano, ma non si tratta di definire le vecchie come "errate" e le nuove come "corrette". E` solo la normale evoluzione della tecnologia (non solo in campo informatico). 
 
Diverso e` il discorso delle metodologie. Personalmente considero quelle agile, iterative/incrementali, un grosso passo avanti nello sviluppo del software. 
 
Ma ora si rischia di divagare troppo :)

Vi ringrazio per la Vs. opinione.