[Architetture (o chiacchiere da bar)] Uso delle stored procedures.

[Scorpio]

Salve a tutti,

solita domanda un po' oziosa un po' seria. Tempo fa stavo revisionando il
codice di un collega e mi sono accorto che, per eseguire l'accesso ai dati,
il collega aveva fatto ricorso in modo esclusivo a delle stored procedures.
Chiestogli il perchè di questa scelta, ha risposto, un po' con l'aria di chi
la sa lunga che *deve* far capire le cosa a chi non la sa altrettanto lunga,
che l'adozione delle stored procedure per accedere ai dati è di gran lunga
la più efficiente.

Io l'ho lasciato ovviamente terminare il lavoro, però dentro la mia testa ha
cominciato a girare una rotellina, ossia un dubbio, su quando sia necessario
ricorrere a delle stored procedure e quando no.

A ben pensarci l'uso delle stored procedures ha dei vantaggi che va al di là
della pura efficienza: ad esempio mi viene in mente la possibilità di
ricompilare le stored procedures "al volo" in caso di modifica dei criteri
per estrarre un certo cursore dal database. Altro esempio che mi viene in
mente è un'operazione di "write" intesa come "insert/update": se fallisce
una insert (perchè il dato esiste già), esegui una update usando una certa
chiave.

Il problema di questo approccio è, chiaramente, la dipendenza dal "dialetto"
specifico del dbms per scrivere le stored procedures. Ma, a parte questo
inconveniente - che può essere nullo se per forza o per amore ci si lega ad
un certo vendor - quali altri svantaggi presentano le s.p ?

La butto lì - un po' provocatoriamente : se (grande SE) non ci fossero i
vari dialetti ma un linguaggio standard per ogni vendor, avrebbe ancora
senso la "rincorsa continua" ai motori di persistenza ?

Scorpio.

[Andrea Francia]

Post by Scorpio
Salve a tutti,
solita domanda un po' oziosa un po' seria. Tempo fa stavo revisionando il
codice di un collega e mi sono accorto che, per eseguire l'accesso ai dati,
il collega aveva fatto ricorso in modo esclusivo a delle stored procedures.
Chiestogli il perchè di questa scelta, ha risposto, un po' con l'aria di chi
la sa lunga che *deve* far capire le cosa a chi non la sa altrettanto lunga,
che l'adozione delle stored procedure per accedere ai dati è di gran lunga
la più efficiente.

Mah? Chissà se è vero? Anche se fosse vale la legge della ottimizzazione
al giusto momento. La cosa piu' importante è produrre codice
manutenibile (a.k.a. leggibile), se i vincoli di prestazioni non sono
raggiunti si deve andare ad intervenire sulle parti del codice che sono
state misurate come le piu' lente.

Post by Scorpio
Il problema di questo approccio è, chiaramente, la dipendenza dal "dialetto"
specifico del dbms per scrivere le stored procedures. Ma, a parte questo
inconveniente - che può essere nullo se per forza o per amore ci si lega ad
un certo vendor - quali altri svantaggi presentano le s.p ?

Ammesso e non concesso che non si voglia considerare il problema della
portabilità l'unica cosa che mi viene in mente è questa.

Un aspetto caratteristico dell'SQL (senza s.p.) è che è dichiarativo e
non imperativo. Non so se questo sia un vantaggio.

Post by Scorpio
La butto lì - un po' provocatoriamente : se (grande SE) non ci fossero i
vari dialetti ma un linguaggio standard per ogni vendor, avrebbe ancora
senso la "rincorsa continua" ai motori di persistenza ?

Cosa intendi con "motori di persistenza", gli ORM?

[Scorpio]

"Andrea Francia"

Post by Andrea Francia
Mah? Chissà se è vero? Anche se fosse vale la legge della ottimizzazione
al giusto momento. La cosa piu' importante è produrre codice manutenibile
(a.k.a. leggibile), se i vincoli di prestazioni non sono raggiunti si deve
andare ad intervenire sulle parti del codice che sono state misurate come
le piu' lente.

Certo, però in un'applicazione datacentrica (ad es, un gestionale) di solito
il tempo maggiore è impiegato
da quei metodi che accedono ai dati, piuttosto che a quelli che eseguono
calcoli.

Post by Andrea Francia
Un aspetto caratteristico dell'SQL (senza s.p.) è che è dichiarativo e non
imperativo. Non so se questo sia un vantaggio.

Dubito che c'entri.

Post by Andrea Francia

Post by Scorpio
La butto lì - un po' provocatoriamente : se (grande SE) non ci fossero i
vari dialetti ma un linguaggio standard per ogni vendor, avrebbe ancora
senso la "rincorsa continua" ai motori di persistenza ?

Cosa intendi con "motori di persistenza", gli ORM?

Esattamente. EJB 2.0 Entity, JPA, Hibernate e via discorrendo: una "corsa
agli armamenti" per risolvere il problema di mappare un bean su una tabella
e viceversa....

Scorpio.

[Andrea Francia]

Post by Scorpio

Post by Andrea Francia

Post by Scorpio
La butto lì - un po' provocatoriamente : se (grande SE) non ci fossero i
vari dialetti ma un linguaggio standard per ogni vendor, avrebbe ancora
senso la "rincorsa continua" ai motori di persistenza ?

Cosa intendi con "motori di persistenza", gli ORM?

Esattamente. EJB 2.0 Entity, JPA, Hibernate e via discorrendo: una "corsa
agli armamenti" per risolvere il problema di mappare un bean su una tabella
e viceversa....

L'esigenza a cui vanno incontro gli ORM e cambiare il modello di
astrazione dei dati da tabelle a oggetti.

Anche se esistesse un SQL standard usato da tutti i vendor credo che
l'esigenza rimarrebbe.

[Andrea Laforgia]

Post by Andrea Francia
Anche se esistesse un SQL standard usato da tutti i vendor credo che
l'esigenza rimarrebbe.

Esigenza per chi ha una visione oggetto-centrica del mondo :-)
Non è un'esigenza sentita comunemente in altri linguaggi/sistemi.

[Andrea Francia]

Post by Andrea Laforgia

Post by Andrea Francia
Anche se esistesse un SQL standard usato da tutti i vendor credo che
l'esigenza rimarrebbe.

Esigenza per chi ha una visione oggetto-centrica del mondo :-)
Non è un'esigenza sentita comunemente in altri linguaggi/sistemi.

D'accordo. Quello che volevo dire è che chi ha quella esigenza c'e' l'ha
anche dopo che arriva l'SQL ultra portabile.

Chi non ce l'ha non ce l'ha.

[n.n]

Il 05 Giu 2008, 10:51, Andrea Francia

Post by Andrea Francia

Post by Andrea Laforgia

Post by Andrea Francia
Anche se esistesse un SQL standard usato da tutti i vendor credo che
l'esigenza rimarrebbe.

Esigenza per chi ha una visione oggetto-centrica del mondo :-)
Non è un'esigenza sentita comunemente in altri linguaggi/sistemi.

D'accordo. Quello che volevo dire è che chi ha quella esigenza c'e' l'ha
anche dopo che arriva l'SQL ultra portabile.
Chi non ce l'ha non ce l'ha.

Concordo in pieno.
La persiostenza dati serve per la portabilita' al 10%

Il grosso dei vantaggi sono l'astrazione a oggetti dei dati, la
cachizzazione, la leggibilita', la manutenibilita'
Infatti anche facendo una stored procedure io utilizzo hibernate per
accederci.

Post by Andrea Francia
--
Andrea Francia
http://www.andreafrancia.it/

Nicola

--------------------------------
Inviato via http://arianna.libero.it/usenet/

[Andrea Laforgia]

Post by n.n
Concordo in pieno.
La persiostenza dati serve per la portabilita' al 10%

Immagino volessi dire al 100%.
Ma in altri linguaggi/sistemi, la portabilità totale si ottiene
ugualmente, anche senza far uso di framework di persistenza e con la
stessa facilità.
Voglio solo sottolineare che usare un framework di persistenza non è
sempre indispensabile.

[n.n]

Post by Andrea Laforgia

Post by n.n
Concordo in pieno.
La persiostenza dati serve per la portabilita' al 10%

Immagino volessi dire al 100%.
Ma in altri linguaggi/sistemi, la portabilità totale si ottiene
ugualmente, anche senza far uso di framework di persistenza e con la
stessa facilità.

E' proprio quello che voglio dire.
Volendo la portabilita' ce la hai usando solo SQL standard.
La portabilita' non e' il vero motivo dell'utilizzo dei framework di
persistenza.

il vero motivo e' che con un framwork l'applicazione e' 2000 volte piu'
ingegnerizzata, pulita, efficiente, manutenibile, ....

Non vorrai mica tornare a scrivere le applicazioni in plsql ......

Post by Andrea Laforgia
Voglio solo sottolineare che usare un framework di persistenza non è
sempre indispensabile.

mahhhhhhh ne dubito, forse per il tetris non serve ...... :-)


Nicola

--------------------------------
Inviato via http://arianna.libero.it/usenet/

[Andrea Laforgia]

Post by n.n
Volendo la portabilita' ce la hai usando solo SQL standard.

Il concetto di "portabilità" è molto lato. Non è affatto detto che bisogna
scrivere SOLO in SQL standard. Puoi lasciare che il 99% della tua
applicazione sia portabile e che l'1% (specifico per la piattaforma) vada
riscritto. Per me questa è comunque portabilità.

Post by n.n
il vero motivo e' che con un framwork l'applicazione e' 2000 volte piu'
ingegnerizzata, pulita, efficiente, manutenibile, ....

Ma non è affatto vero che SOLO con un framework, ottieni questi risultati.
Attenzione a dire 'ste cose. In altri sistemi (non voglio andare troppo
nel tecnico perché sarebbe OT), si fa benissimo a meno di un framework di
persistenza per adottare tecniche ugualmente efficienti, pulite e
manutenibili.

Post by n.n

Post by Andrea Laforgia
Voglio solo sottolineare che usare un framework di persistenza non è
sempre indispensabile.

mahhhhhhh ne dubito, forse per il tetris non serve ...... :-)

Mi prendi in giro? non è così. Probabilmente hai una visione troppo
java-centric dello sviluppo.

[n.n]

Post by Andrea Laforgia

Post by n.n
Volendo la portabilita' ce la hai usando solo SQL standard.

Il concetto di "portabilità" è molto lato. Non è affatto detto che bisogna
scrivere SOLO in SQL standard. Puoi lasciare che il 99% della tua
applicazione sia portabile e che l'1% (specifico per la piattaforma) vada
riscritto. Per me questa è comunque portabilità.

Post by n.n
il vero motivo e' che con un framwork l'applicazione e' 2000 volte piu'
ingegnerizzata, pulita, efficiente, manutenibile, ....

Ma non è affatto vero che SOLO con un framework, ottieni questi risultati.
Attenzione a dire 'ste cose. In altri sistemi (non voglio andare troppo
nel tecnico perché sarebbe OT), si fa benissimo a meno di un framework di
persistenza per adottare tecniche ugualmente efficienti, pulite e
manutenibili.

Post by n.n

Post by Andrea Laforgia
Voglio solo sottolineare che usare un framework di persistenza non è
sempre indispensabile.

mahhhhhhh ne dubito, forse per il tetris non serve ...... :-)

Mi prendi in giro? non è così.

No dai, e' un 3d di discussioni architetturali ed e' giusto sentire le
campane di vari architect

Post by Andrea Laforgia
Probabilmente hai una visione troppo
java-centric dello sviluppo.

E' molto probabile.
Una volta ero piu' multipiattaforma. Oggi all'11esimo anno di Java senza
dubbio un po' di visione globale la ho persa ;-)

Nicola

--------------------------------
Inviato via http://arianna.libero.it/usenet/

[cicap]

Post by Andrea Laforgia
Ma non è affatto vero che SOLO con un framework, ottieni questi risultati.
Attenzione a dire 'ste cose. In altri sistemi (non voglio andare troppo
nel tecnico perché sarebbe OT), si fa benissimo a meno di un framework di
persistenza per adottare tecniche ugualmente efficienti, pulite e
manutenibili.

Quali sarebbero questi sistemi / linguaggi (mi pareva che avevi parlato
di linguaggi e piattaforme altrove ma non ne sono sicuro)?

[Andrea Laforgia]

On Tue, 3 Jun 2008 22:44:42 +0200, "Scorpio"

Post by Scorpio
Io l'ho lasciato ovviamente terminare il lavoro, però dentro la mia testa ha
cominciato a girare una rotellina, ossia un dubbio, su quando sia necessario
ricorrere a delle stored procedure e quando no.

Per essere efficiente, è efficiente (anche perché di solito le s.p.
sono precompilate dal DBMS), ma il problema è più che altro di
approcci. Nell'azienda in cui lavoro come consulente, c'è una
suddivisione del lavoro tra analisti, sviluppatori, DBA, ecc...

La politica del cliente è che qualsiasi gestione dei dati passa da una
procedura o funzione Oracle. Questo approccio ha diversi "drawbacks",
come l'essere un cannone per sparare alle mosche in molti casi,
l'obbligo a scrivere codice di fatto procedurale, difficilmente
debuggabile, difficilmente integrabile, ecc.. ecc..

I vantaggio, sostanzialmente, sono l'isolamento del codice di accesso
e gestione dati in un punto solo, la possibilità di correggere errori
senza dover ridistribuire l'applicazione, l'efficienza di cui sopra,
la possibilità di assegnare il compito di scrittura di una determinata
procedura a chi conosce il DB molto meglio dello sviluppatore. Io
scrivo tranquillamente le mie procedure/funzioni in PL/SQL, però
ammetto di aver dovuto chiedere spesso chiarimenti ai DBA, per
particolari statement, e questo è sicuramente tempo perso.

[Roberto Montaruli]

Post by Scorpio
Salve a tutti,
solita domanda un po' oziosa un po' seria. Tempo fa stavo revisionando il
codice di un collega e mi sono accorto che, per eseguire l'accesso ai dati,
il collega aveva fatto ricorso in modo esclusivo a delle stored procedures.
Chiestogli il perchè di questa scelta, ha risposto, un po' con l'aria di chi
la sa lunga che *deve* far capire le cosa a chi non la sa altrettanto lunga,
che l'adozione delle stored procedure per accedere ai dati è di gran lunga
la più efficiente.
Io l'ho lasciato ovviamente terminare il lavoro, però dentro la mia testa ha
cominciato a girare una rotellina, ossia un dubbio, su quando sia necessario
ricorrere a delle stored procedure e quando no.

In diverse mie applicazioni che devono operare su un DB, abbiamo deciso
di fare uso delle stored procedures, per poter centralizzare in un unico
punto le operazioni di lettura e scrittura, e mettiamo a disposizione
quelle a tutte le applicazioni che devono leggere e scrivere gli stessi
dati.

Nel mio caso l'efficienza e' strettamente legata alla manutenzione del
codice e all'eliminazione di inutili ridondanze.

Se invece parliamo di efficienza in termini di performance
dell'applicazione, si sgrava l'applicazione esterna dal possedere del
codice SQL embedded, che probabilmente potrebbe venire scritto male, e
inserendolo in una stored procedure, questo puo' essere testato
indipendentemente dall'applicazione.

Se pero' non ci sono problematiche di riutilizzo e il codice SQL e'
efficiente di suo, io non credo che vi sia piu' di tanta differenza di
performance ad averlo embedded piuttosto che in una stored procedure.
Tanto la connessione al server SQL deve avvenire comunque.
Il server deve eseguire la query comunque.
Averci i comandi SQL gia' sul server piuttosto che passarli con un
metodo, cambia ben poco.

A meno che l'operazione da fare sia quella di travasare un recordset in
un altro, che allora nel caso della stored procedure, resta tutto sul
server, mentre usando un recordset sul client bisogna recuperare i dati
per poi rimandarli indietro, e allora si' che si appesantisce tutto.

In conclusione direi proprio che ci sono casi in cui la stored procedure
e' piu' efficiente, e altri in cui e' indifferente.
In nessun caso e' piu' efficiente una executeQuery embedded, quindi il
tuo collega qualche ragione ce l'ha.

[Andrea Laforgia]

Post by Roberto Montaruli
Se pero' non ci sono problematiche di riutilizzo e il codice SQL e'
efficiente di suo, io non credo che vi sia piu' di tanta differenza di
performance ad averlo embedded piuttosto che in una stored procedure.
Tanto la connessione al server SQL deve avvenire comunque.
Il server deve eseguire la query comunque.
Averci i comandi SQL gia' sul server piuttosto che passarli con un
metodo, cambia ben poco.

Nel caso dell'invocazione della SP, a parte l'ottimizzazione spicciola di
non dover passare troppi dati dal client al server, c'è di buono che il
codice della SP è compilato, sul server. Lo stesso di ottiene con la
prepare degli statement, ma almeno la prima volta c'è un po' di lavoro in
più. Quindi comunque il sistema delle SP è più efficiente.

[Davide Consonni]

il la faccio abbastanza semplice stored procedure solo per necessità di
prestazioni o casi molto particolari, per il resto c'è java, codice molto
più facile da mantenere, da debuggare, da portare ..

poi dipende come sempre dal cliente e progetto, alle volte non è una
scelta :D

[Pablo Xon]

Post by Scorpio
Chiestogli il perchè di questa scelta, ha risposto, un po' con l'aria di chi
la sa lunga che *deve* far capire le cosa a chi non la sa altrettanto lunga,
che l'adozione delle stored procedure per accedere ai dati è di gran lunga
la più efficiente.

IMHO ha poco senso discutere di architetture se non se ne conosce
l'ambito di utilizzo ed impiego: è ben diverso sviluppare
un'applicazione di integrazione sistemi su cui lavorano 20 programmatori
e una per un sw specialistico su cui ne lavorano 2.

Post by Scorpio
A ben pensarci l'uso delle stored procedures ha dei vantaggi che va al di là
della pura efficienza: ad esempio mi viene in mente la possibilità di
ricompilare le stored procedures "al volo" in caso di modifica dei criteri
per estrarre un certo cursore dal database. Altro esempio che mi viene in
mente è un'operazione di "write" intesa come "insert/update": se fallisce
una insert (perchè il dato esiste già), esegui una update usando una certa
chiave.

Quest'ultimo esempio non mi sembra molto significativo, lo si può
egualmente implementare lato applicativo.
Il fatto di poter utilizzare le sp "esternamente" all'applicazione,
invece, è molto utile, soprattutto se ci si trova in un ambiente
eterogeneo dove applicazioni (molto) diverse devono interagire.
Di certo l'efficenza è il fattore determinante.

Post by Scorpio
Il problema di questo approccio è, chiaramente, la dipendenza dal "dialetto"
specifico del dbms per scrivere le stored procedures. Ma, a parte questo
inconveniente - che può essere nullo se per forza o per amore ci si lega ad
un certo vendor - quali altri svantaggi presentano le s.p ?

Per esperienza (ho iniziato a lavorare sui db nell'87) sono
assolutamente convinto che legarsi troppo a un determinato vendor sia
_sempre_ una scelta deleteria.
Tanto per fare un esempio: tra due ore devo incontrarmi con un cliente
cui, circa 10 anni fa, hanno venduto una soluzione pesantemente basata
su un diffuso (il più diffuso, senza fare nomi ;) ) rdbms: ora, stanco
di pagare circa 80mila euro l'anno solo di licenze del db, vorrebbe
migrare tutto...

Oggi, con il gran numero di db con licenza libera, la situazione è un
(bel) po' migliorata ma credo ci sia ancora parecchia strada da fare.
Altro svantaggio delle sp è una certa limitatezza (sia come struttura
che come documentazione, per non parlare della "costanza" nel tempo) dei
linguaggi usati per implementarle.

Post by Scorpio
La butto lì - un po' provocatoriamente : se (grande SE) non ci fossero i
vari dialetti ma un linguaggio standard per ogni vendor, avrebbe ancora
senso la "rincorsa continua" ai motori di persistenza ?

Dici bene: "grande SE".
Già ora non è raro, anzi, trovare discrepanze nel linguaggio SQL, non
oso pensare al risultato se si cercasse di standardizzare anche le sp (e
proposte ne son state fatte parecchie) ;)

Ciao,
Paolo

[Andrea Laforgia]

Post by Pablo Xon
Tanto per fare un esempio: tra due ore devo incontrarmi con un cliente
cui, circa 10 anni fa, hanno venduto una soluzione pesantemente basata
su un diffuso (il più diffuso, senza fare nomi ;) ) rdbms: ora, stanco
di pagare circa 80mila euro l'anno solo di licenze del db, vorrebbe
migrare tutto...

E che ci vuole! Oracle --> Postgres :-)

[Scorpio]

Post by Andrea Laforgia
E che ci vuole! Oracle --> Postgres :-)

Giusto per non fare nomi,vero ? :-)

Scorpio

[Andrea Laforgia]

Post by Andrea Laforgia

Post by Pablo Xon
Tanto per fare un esempio: tra due ore devo incontrarmi con un cliente
cui, circa 10 anni fa, hanno venduto una soluzione pesantemente basata
su un diffuso (il più diffuso, senza fare nomi ;) ) rdbms: ora, stanco
di pagare circa 80mila euro l'anno solo di licenze del db, vorrebbe
migrare tutto...

E che ci vuole! Oracle --> Postgres :-)

Guarda, finquando si fosse limitato a "il più diffuso rdbms", il
raggio sarebbe stato ancora ampio, ma poi ha aggiunto 80mila euro
l'anno di licenze e si è fregato :-P

[Pablo Xon]

Post by Andrea Laforgia
E che ci vuole! Oracle --> Postgres :-)

Beh dai, era facile! ;)
Un po' meno facile migrare circa 18Gb di db, con parecchie tabelle piene
di "schifezzuole"... vedrem.

Ciao,
Paolo

[Hole]

Post by Pablo Xon

Post by Andrea Laforgia
E che ci vuole! Oracle --> Postgres :-)

Beh dai, era facile! ;)
Un po' meno facile migrare circa 18Gb di db, con parecchie tabelle piene
di "schifezzuole"... vedrem.
Ciao,
Paolo

siete davvero sicuri di voler passare da oracle a postgres? :)

La gestione delle transazioni in postgres è molto diversa da quella in
oracle. E' molto più limitata e molte SP potrebbero essere inservibili
e da rifattorizzare pesantemente.
Si attendono smentite.

[Pablo Xon]

Post by Hole
siete davvero sicuri di voler passare da oracle a postgres? :)

No, dicevo che era facile intuire che il "il più diffuso" db era Oracle :)
Sul "dove" passare è ancora tutto al vaglio...

Post by Hole
E' molto più limitata e molte SP potrebbero essere inservibili
e da rifattorizzare pesantemente.
Si attendono smentite.

Non da me :)
L'unica fortuna è che nel db oracle ci sono pochissime S.P..
Le cose che più mi preoccupano sono altre, ma non sto qui ad annoiarti...

Ciao,
Paolo

[Scorpio]

IMHO ha poco senso discutere di architetture se non se ne conosce l'ambito
di utilizzo ed impiego: è ben diverso sviluppare un'applicazione di
integrazione sistemi su cui lavorano 20 programmatori e una per un sw
specialistico su cui ne lavorano 2.

Non hai torto.

Quest'ultimo esempio non mi sembra molto significativo, lo si può
egualmente implementare lato applicativo.

Facendo due chiamate però: la prima per verificare se l'update è andata a
buon fine;
la seconda per eseguire l'eventuale insert.

Dici bene: "grande SE".
Già ora non è raro, anzi, trovare discrepanze nel linguaggio SQL, non oso
pensare al risultato se si cercasse di standardizzare anche le sp (e
proposte ne son state fatte parecchie) ;)

Vero, è un "grande se" il mio....

Ciao,
Scorpio.

[rootkit]

Post by Scorpio
solita domanda un po' oziosa un po' seria. Tempo fa stavo revisionando il
codice di un collega e mi sono accorto che, per eseguire l'accesso ai dati,
il collega aveva fatto ricorso in modo esclusivo a delle stored procedures.
Chiestogli il perchè di questa scelta, ha risposto, un po' con l'aria di chi
la sa lunga che *deve* far capire le cosa a chi non la sa altrettanto lunga,
che l'adozione delle stored procedure per accedere ai dati è di gran lunga
la più efficiente.

una stored procedure è più efficiente se racchiude una sequenza di
istruzioni sql. ma se mappa 1:1 le stored procedure con le istruzioni
sql su che basi dice che è più efficiente?

Post by Scorpio
Il problema di questo approccio è, chiaramente, la dipendenza dal "dialetto"
specifico del dbms per scrivere le stored procedures. Ma, a parte questo
inconveniente - che può essere nullo se per forza o per amore ci si lega ad
un certo vendor - quali altri svantaggi presentano le s.p ?

per quanto riguarda l'utilizzo sopra citato, che sostanzialmente un
abuso dello strumento, lo svantaggio è che come minimo non c'è vantaggio.

in generale però l'uso delle stored procedure consiste nello spostare
una parte della logica applicativa da java al database e questo è uno
svantaggio. e più sposti la logica sul db, più aumenta la necessità di
gestire anche le transazioni a quel livello; se cominci a mettere
commit/rollback nelle stored procedure ti puoi scordare tutti i bei
discorsi sulle transazioni degli ejb, di spring, di gestione
dichiarativa delle transazioni e compagnia danzante.

[Andrea Laforgia]

Post by rootkit
una stored procedure è più efficiente se racchiude una sequenza di
istruzioni sql. ma se mappa 1:1 le stored procedure con le istruzioni
sql su che basi dice che è più efficiente?

In realtà - come in tutte le cose - usare male le s.p. può creare
situazioni di assoluta inefficienza. Mi rendo conto che sto per citare
un caso eclatante, ma io ho dovuto fare manutenzione su un sistema in
cui tutta la logica era stata spostata su DB, al livello tale (e qui
sta l'inghippo) che delle pure e semplici select venivano racchiuse in
GET_VATTELAPESCA restituenti dei cursori, le quali adottavano
l'intelligente politica di aprire un cursore per la select in
questione, scorrere tutti i record e sputarli, uno per uno, sul
recordset da restituire. Risultato: s.p. di questo tipo (e ce n'erano
una novantina, non scherzo), scritte da dementi, invalidavano
qualsiasi indice potessi aggiungere alle tabelle, essendo alla fine
tutti scorrimenti (!). L'ennesima patata bollente che aveva fatto
venire al cliente i capelli ritti e che abbiamo dovuto riscrivere da
zero.

Post by rootkit
in generale però l'uso delle stored procedure consiste nello spostare
una parte della logica applicativa da java al database e questo è uno
svantaggio.

Non essere così categorico: dipende dai contesti. Anch'io ho creduto
per un certo tempo che fosse sempre bene mantenere la logica a un
livello meglio organizzabile, manutenibile e su cui fosse abbastanza
facile intervenire. Mi sono poi reso conto che quando c'è eterogeneità
di sistemi, spostare la logica di business su database (se non altro
come politica aziendale) non è una cattiva idea (fermi restando gli
svantaggi di cui parlavo in un altro post... s'intende). In linea di
massima sono d'accordo con te, però dipende molto dalle situazioni.

[cicap]

Post by Andrea Laforgia
Mi sono poi reso conto che quando c'è eterogeneità
di sistemi, spostare la logica di business su database (se non altro
come politica aziendale) non è una cattiva idea (fermi restando gli
svantaggi di cui parlavo in un altro post... s'intende). In linea di
massima sono d'accordo con te, però dipende molto dalle situazioni.

Quando, secondo te, e' utile spostare parte della logica di business
nella base dati?

[Andrea Laforgia]

Post by cicap
Quando, secondo te, e' utile spostare parte della logica di business
nella base dati?

A volte è una pura e semplice scelta politica, comunque è una cosa
logica da fare quando ci sono sistemi eterogenei che devono sfruttare
le stesse regole di business, oppure c'è una suddivisione netta tra
chi scrive il codice e chi gestisce e ottimizza il DB. A volte questa
divisione è utile perché fa risparmiare tempo. Per esempio, a me è
capitato (per strane logiche del cliente, ma è un altro discorso) di
dover scrivere un processo che travasava, a intervalli definiti e
tramite un dblink Oracle, dei dati da una tabella all'altra, dovendo
stare attento ad aggiungere i nuovi record ed aggiornare quelli già
presenti. Ovviamente la prima cosa a cui ho pensato è di fare
controlli mediante i soliti comandi SQL. Oracle, invece, mette a
disposizione la potentissima istruzione MATCH. L'ho trovata perché ho
cercato, però magari tanta gente la briga di cercare queste
informazioni manco se la piglia.

[cicap]

Post by Andrea Laforgia

Post by cicap
Quando, secondo te, e' utile spostare parte della logica di business
nella base dati?

A volte è una pura e semplice scelta politica, comunque è una cosa
logica da fare quando ci sono sistemi eterogenei che devono sfruttare
le stesse regole di business, oppure c'è una suddivisione netta tra
chi scrive il codice e chi gestisce e ottimizza il DB

Non centra niente con le stored procedure e il database, ma recentemente
ho un problema di dove e come piazzare la logica: devo fare un insieme
di applicazioni client (che comunicano con webservice) che variano piu'
o meno leggermente nella logica di presentazioni e di business.
Disegnare il modello ad oggetti, sparpagliando la logica dentro i getter
/ setter se si tratta di piccole cose, o dentro la view stessa (ma si
tratta di if semplici come se dato A e' presente e vale X allora mostra
anche campo B) oppure dentro i bean per la logica di business mi
costringerebbe a grossi lavori di manutenzione e non solo.
A questo aggiungiamo che le regole sembrano essere molte abbastanza
soggette a variazioni.

Ora la prima applicazione l'ho fatta cosi', sparpagliando le logiche di
quel tipo. Ora siamo alla seconda e si presenta evidente il problema.
Come procedere ora?

[rootkit]

Post by cicap
Non centra niente con le stored procedure e il database, ma recentemente
ho un problema di dove e come piazzare la logica: devo fare un insieme
di applicazioni client (che comunicano con webservice) che variano piu'
o meno leggermente nella logica di presentazioni e di business.
Disegnare il modello ad oggetti, sparpagliando la logica dentro i getter
/ setter se si tratta di piccole cose, o dentro la view stessa (ma si
tratta di if semplici come se dato A e' presente e vale X allora mostra
anche campo B) oppure dentro i bean per la logica di business mi
costringerebbe a grossi lavori di manutenzione e non solo.
A questo aggiungiamo che le regole sembrano essere molte abbastanza
soggette a variazioni.
Ora la prima applicazione l'ho fatta cosi', sparpagliando le logiche di
quel tipo. Ora siamo alla seconda e si presenta evidente il problema.
Come procedere ora?

sicuramente il fatto che usi il termine "sparpagliare" è indice che non
hai fatto un gran lavoro di progettazione... :)

non posso entrare nel tuo caso specifico, ma fintanto ho utilizzato un
modello a tre livelli con i dao orientati al database (con metodi che
mappano l'accesso diretto alle tabelle), i manager orientati alla logica
applicativa (con metodi che mappano le operazioni di business logic) e i
model che mappano le richieste del view, l'ultimo dei miei problemi è
stato proprio la manutenibilità (almeno per il problema di trovare il
codice da manutenere, poi è ovvio che non c'è una singola soluzione a
tutti i problemi). non solo, ma nel momento in cui voglio passare da
spring a ejb3 o viceversa, oppure voglio pubblicare la mia logica in un
web service, il costo è realmente zero. inoltre ponendomi l'obbligo (e
ponendolo ai programmatori) di astrarre sempre una interfaccia anche sui
dao, mi smarco dai vincoli di un motore di persistenza per
l'applicativo: posso avere un dao che usa hibernate, uno che usa il jdbc
nudo e crudo e anche un dao che ha due implementazioni diverse, poi se
il manager usa uno o l'altro lo configuro in modo dichiarativo.

si può obiettare che per un progetto di piccole dimensioni sia
sovraingegnerizzato, ma per quanto mi riguarda questo pesa solo sullo
startup (e neanche tanto, una volta ti sei creato un archetype).

[cicap]

Post by rootkit

Post by cicap
Ora la prima applicazione l'ho fatta cosi', sparpagliando le logiche
di quel tipo. Ora siamo alla seconda e si presenta evidente il
problema. Come procedere ora?

sicuramente il fatto che usi il termine "sparpagliare" è indice che non
hai fatto un gran lavoro di progettazione... :)

Mi sa che hai letto solo l'ultimo paragrafo oppure non mi sono fatto capire.

Non credo che quando programmi un'applicazione web tradizionale NON
tendi a sparagliare cose come

public int getFirstAndLastNAme() {
return first + " " + lastName;
}

oppure

<h:inputText value="..." rendered="#{a ? true : b.c}"/>


I DAO, service ecc non sono fatti per contenere logiche di questo tipo.

[rootkit]

Post by cicap
Mi sa che hai letto solo l'ultimo paragrafo oppure non mi sono fatto capire.
Non credo che quando programmi un'applicazione web tradizionale NON
tendi a sparagliare cose come
public int getFirstAndLastNAme() {
return first + " " + lastName;
}
oppure
<h:inputText value="..." rendered="#{a ? true : b.c}"/>
I DAO, service ecc non sono fatti per contenere logiche di questo tipo.

ma questi sarebbero esempi di business logic?
forse è meglio se fai un esempio più concreto, perchè forse si è vero
che non ho capito e questi esempi non mi aiutano certo :)

per inciso, a mio avviso il primo è una proprietà transient dell'entità
persistente, mentre sul secondo non vedo il problema...

[Alessandro Cara]

rootkit wrote:
[cut]

Post by rootkit

Post by cicap
public int getFirstAndLastNAme() {
return first + " " + lastName;
}

[cut]

Post by rootkit
per inciso, a mio avviso il primo è una proprietà transient dell'entità
persistente, mentre sul secondo non vedo il problema...

Non ho capito. Cos'e' una "proprieta transient dell'entita' persistente"?
Se "transient" e' il transiente italiano mi sembra una contraddizione in
termini. Fermo restando che non ho capito nemmeno per quale motivo "il
primo" dovrebbe essere all'interno di una entita' persistente

[rootkit]

Post by Alessandro Cara
[cut]

Post by rootkit

Post by cicap
public int getFirstAndLastNAme() {
return first + " " + lastName;
}

[cut]

Post by rootkit
per inciso, a mio avviso il primo è una proprietà transient
dell'entità persistente, mentre sul secondo non vedo il problema...

Non ho capito. Cos'e' una "proprieta transient dell'entita' persistente"?

una proprietà annotata @Transient della @Entity persistente che
definisce firstName e lastName.

[Alessandro Cara]

Post by rootkit

Post by Alessandro Cara
[cut]

Post by rootkit

Post by cicap
public int getFirstAndLastNAme() {
return first + " " + lastName;
}

[cut]

Post by rootkit
per inciso, a mio avviso il primo è una proprietà transient
dell'entità persistente, mentre sul secondo non vedo il problema...

Non ho capito. Cos'e' una "proprieta transient dell'entita' persistente"?

definisce firstName e lastName.

Va bene. Ma questa cosa in cio' che ha scritto cicap dove stava?
E comunque continua ad essere una contraddizione in termini.
Questa e' la prima volta che la vedo. Vabbe' non e' che sia un
"conoscitore" di java (il linguaggio). Visto che ci sei, quale
"problema" dovrebbe risolvere questa notazione e cosa aggiunge in
chiarezza e come serve per evitare "l'ufficio complicazioni affari
semplici"?
O forse serve ad alimentarlo? ;<)

[rootkit]

Post by Alessandro Cara

Post by rootkit
definisce firstName e lastName.

Va bene. Ma questa cosa in cio' che ha scritto cicap dove stava?

in quello che ha scritto cicap io *suppongo* che lui abbia una entity
che descrive una persona, con nome e cognome, e voglia mettere da
qualche parte una proprietà che sia la concatenazione dei due. io gli ho
suggerito di fare in questo modo.
la mia supposizione era sbagliata? poco male, skippi pure il mio messaggio.

Post by Alessandro Cara
E comunque continua ad essere una contraddizione in termini.
Questa e' la prima volta che la vedo. Vabbe' non e' che sia un
"conoscitore" di java (il linguaggio). Visto che ci sei, quale
"problema" dovrebbe risolvere questa notazione e cosa aggiunge in
chiarezza e come serve per evitare "l'ufficio complicazioni affari
semplici"?
O forse serve ad alimentarlo? ;<)

se vuoi discutere del sesso degli angeli hai sbagliato campanello.
ma non disperare, qualcuno disponibile c'è.

[Alessandro Cara]

Post by rootkit

Post by Alessandro Cara

Post by rootkit
definisce firstName e lastName.

Va bene. Ma questa cosa in cio' che ha scritto cicap dove stava?

in quello che ha scritto cicap io *suppongo* che lui abbia una entity
che descrive una persona, con nome e cognome, e voglia mettere da
qualche parte una proprietà che sia la concatenazione dei due. io gli ho
suggerito di fare in questo modo.
la mia supposizione era sbagliata? poco male, skippi pure il mio messaggio.

Ho forse scritto che era *sbagliata*?.
Io sono abituato a usare *proprieta'* in sola lettura (cfr. A. Francia,
se ho capito cosa intendeva) non vedevo che male potesse esserci a usare
il solo *getter* magari facendo riferimento ai metodi base i.e.
this.getFirstName() + " " + this.getLastName() che, *suppongo*, ci siano.
Tu hai introdotto una considerazione riguardante la gestione della
persistenza dei dati. Se, come tutti tendono a fare, vogliono separare
la *elaborazione* (uso questa parola al posto di business) dal dato
grezzo, il "calcolo" della anagrafica dovrebbe essere spostato nell'area
della elaborazione. La domanda e': ma vale la pena di di spostare in
quell'area logiche' cosi' vicine al dato? Prendendo a prestito da "basi
di dati", in alcuni casi non e' conveniente *denormalizzare* per non
*sparpagliare* ogni piu' piccola cosa fra i vari componenti?
Da questo mi sembra nasca la necessita di *annotare* al sistema che quel
dato non ha obbligo di persistenza.
Sono abbastanza inesperto da non cogliere tante sottigliezze e quindi mi
si pone un'altra domanda: essendo getFirstAndLastName un metodo di
accesso al dato perche' dovrebbe incidere sulla gestione della
persistenza? Tutto cio' a meno che il "@Transient" non sia semplicemente
una annotazione che non ha alcuna ricaduta sul trattamento dei dati.

Post by rootkit

Post by Alessandro Cara
E comunque continua ad essere una contraddizione in termini.
Questa e' la prima volta che la vedo. Vabbe' non e' che sia un
"conoscitore" di java (il linguaggio). Visto che ci sei, quale
"problema" dovrebbe risolvere questa notazione e cosa aggiunge in
chiarezza e come serve per evitare "l'ufficio complicazioni affari
semplici"?
O forse serve ad alimentarlo? ;<)

se vuoi discutere del sesso degli angeli hai sbagliato campanello.

Talvolta mi succede.
Sul sesso degli angeli c'e' poco da dire.
Lo scelgono in base a come gli tira ed e' sempre diverso da quello da
noi indicato.

Post by rootkit
ma non disperare, qualcuno disponibile c'è.

non v'e' alcun problema. Male che vada mi cerco un po' di letteratura.

[rootkit]

Post by Alessandro Cara

Post by rootkit
la mia supposizione era sbagliata? poco male, skippi pure il mio messaggio.

Ho forse scritto che era *sbagliata*?.

peggio mi sento, così la polemica è ancora più gratuita.

[Andrea Francia]

Post by rootkit

Post by Alessandro Cara
[cut]

Post by rootkit

Post by cicap
public int getFirstAndLastNAme() {
return first + " " + lastName;
}

[cut]

Post by rootkit
per inciso, a mio avviso il primo è una proprietà transient
dell'entità persistente, mentre sul secondo non vedo il problema...

Non ho capito. Cos'e' una "proprieta transient dell'entita' persistente"?

definisce firstName e lastName.

Nel caso specifico credo che sia sufficiente fare una proprietà readonly.

[Andrea Francia]

Post by Andrea Francia

Post by rootkit

Post by Alessandro Cara
[cut]

Post by rootkit

Post by cicap
public int getFirstAndLastNAme() {
return first + " " + lastName;
}

[cut]

Post by rootkit
per inciso, a mio avviso il primo è una proprietà transient
dell'entità persistente, mentre sul secondo non vedo il problema...

Non ho capito. Cos'e' una "proprieta transient dell'entita'
persistente"?

definisce firstName e lastName.

Nel caso specifico credo che sia sufficiente fare una proprietà readonly.

Ho detto una mezza stupidata.

Se crei una proprietà readonly devi digli che @Transient come dice, al
solito giustamente, rootkit se no la JPA si arrabbia.

[cicap]

Post by rootkit

Post by cicap
Mi sa che hai letto solo l'ultimo paragrafo oppure non mi sono fatto capire.
Non credo che quando programmi un'applicazione web tradizionale NON
tendi a sparagliare cose come
public int getFirstAndLastNAme() {
return first + " " + lastName;
}
oppure
<h:inputText value="..." rendered="#{a ? true : b.c}"/>
I DAO, service ecc non sono fatti per contenere logiche di questo tipo.

ma questi sarebbero esempi di business logic?

Logica di presentazione.

Post by rootkit
forse è meglio se fai un esempio più concreto, perchè forse si è vero
che non ho capito e questi esempi non mi aiutano certo :)

Immagina di avere 'n' campi da visualizzare in varie pagine. In baso
allo stato di alcuni di questi campi, altri campi devono essere
visualizzati o meno, essere readonly o meno, avere certe regole di
validazione o meno.
Ora immagina anche di avere 10 applicazioni da costruire in questo modo,
con una struttura molto simile ma dove le regole variano leggermente
l'una dall'altra. E dove all'iterno dello stesso progetto queste regole
sono piuttosto mutevoli.

Tutte interrogano comunque lo stesso webservice (e non ho database).

Normalmente queste regole si piazzano dentro le proprieta' dei bean. In
questo caso invece mi sembra un problema perche' avrei una merea di bean
simili con regole diverse sparpagliate tra i vari getter / setter.

Inoltre avrei anche una marea di logica in pagina e, anche se si tratta
di espressioni semplici, rende le cose piuttosto immantenibili.

Dopo un po' di ricerca mi sembra che invece di incastonare la logica
dentro al domionio ad oggetti, sia il caso di rilassare tale
infrastruttura (generalizzandola) e spostare la logica di presentazione
e validazione dentro classi che implementano le regole.
A questo punto serve un motore che le richiama automaticamente nel
momento giusto.

Sembra anche che una tale infrastruttura mi porti verso un rule engine
(vedi Drools ad esempio), dove un giorno potro' sostitiure le classi di
logica con regole scritte per tale sistema. Addirittura il webservice
potra' fornire le regole che costituiscono la mia logica (visto che
molte di esse servono anche a lui).

[Andrea Francia]

Post by cicap

Post by Andrea Laforgia

Post by cicap
Quando, secondo te, e' utile spostare parte della logica di business
nella base dati?

A volte è una pura e semplice scelta politica, comunque è una cosa
logica da fare quando ci sono sistemi eterogenei che devono sfruttare
le stesse regole di business, oppure c'è una suddivisione netta tra
chi scrive il codice e chi gestisce e ottimizza il DB

Non centra niente con le stored procedure e il database, ma recentemente
ho un problema di dove e come piazzare la logica: devo fare un insieme
di applicazioni client (che comunicano con webservice) che variano piu'
o meno leggermente nella logica di presentazioni e di business.
Disegnare il modello ad oggetti, sparpagliando la logica dentro i getter
/ setter se si tratta di piccole cose, o dentro la view stessa (ma si
tratta di if semplici come se dato A e' presente e vale X allora mostra
anche campo B) oppure dentro i bean per la logica di business mi
costringerebbe a grossi lavori di manutenzione e non solo.

Non sono sicuro di aver capito.

Tu hai un bean così (non scrivo i public):

class Person {
String getFirstName() {...}
String getLastName() {...}
}

Pero' hai bisogno anche di aggiungere
String getFullName() {
return firstName + " " + lastName;
}

però non vuoi metterlo dentro il bean per motivi vari (costi di
manutenzione, regole che cambiano spesso).

In questo caso fai un bean PersonView che esiste solo nella view che
mima Person ma aggiunge la proprietà read-only 'fullName' calcolata al volo.

class PersonView {
Person delegate;

PersonView(Person delegate) {
this.delegate = delegate;
}

String getFirstName() {
return delegate.getFirstName();
}

String getLastName() {
return delegate.getLastName();
}

String getFullName() {
return delegate.getFirstName() + " " + delegate.getLastName();
}
}

[rootkit]

Post by Andrea Francia
In questo caso fai un bean PersonView che esiste solo nella view che
mima Person ma aggiunge la proprietà read-only 'fullName' calcolata al volo.

ufficio complicazioni affari semplici, eh... :)

[Andrea Francia]

Post by rootkit

Post by Andrea Francia
In questo caso fai un bean PersonView che esiste solo nella view che
mima Person ma aggiunge la proprietà read-only 'fullName' calcolata al volo.

ufficio complicazioni affari semplici, eh... :)

E ma se non puo' modificare il bean che puoi fare se no?

[rootkit]

Post by Andrea Francia

Post by rootkit
ufficio complicazioni affari semplici, eh... :)

E ma se non puo' modificare il bean che puoi fare se no?

se proprio non può modificare il bean vorrà dire che nome e cognome li
stamperà con due h:outputText invece che uno.
le soluzioni non possono essere più complicate del problema...

[Andrea Francia]

Post by rootkit

Post by Andrea Francia

Post by rootkit
ufficio complicazioni affari semplici, eh... :)

E ma se non puo' modificare il bean che puoi fare se no?

se proprio non può modificare il bean vorrà dire che nome e cognome li
stamperà con due h:outputText invece che uno.
le soluzioni non possono essere più complicate del problema...

Anche.
Dipende se deve farlo una volta o ennemila.

Se poi cambia la regola da Fullname = FirstName + LastName in FullName =
Lastname + FirstName.

Bisogna andare a scovare in tutti i posti hai fatto la concatenazione a
mano.

[cicap]

Post by rootkit

Post by Andrea Francia

Post by rootkit
ufficio complicazioni affari semplici, eh... :)

E ma se non puo' modificare il bean che puoi fare se no?

se proprio non può modificare il bean vorrà dire che nome e cognome li
stamperà con due h:outputText invece che uno.

Non sia mai ;)

#{user.firstName} #{user.lastName}

Grazie a Jacob Hookom...

[Andrea Francia]

Post by cicap

Post by rootkit

Post by Andrea Francia

Post by rootkit
ufficio complicazioni affari semplici, eh... :)

E ma se non puo' modificare il bean che puoi fare se no?

se proprio non può modificare il bean vorrà dire che nome e cognome li
stamperà con due h:outputText invece che uno.

Non sia mai ;)
#{user.firstName} #{user.lastName}
Grazie a Jacob Hookom...

Spiega questa citazione per favore.

[cicap]

Post by Andrea Francia

Post by cicap

Post by rootkit
se proprio non può modificare il bean vorrà dire che nome e cognome
li stamperà con due h:outputText invece che uno.

Non sia mai ;)
#{user.firstName} #{user.lastName}
Grazie a Jacob Hookom...

Spiega questa citazione per favore.

Non e' una citazione ma un ringraziamento a Hookom, il creatore di
Facelets. Egli ci ha sollevato dal dover piazzare componenti
<h:outputText/> in ogni dove.

[Andrea Francia]

Post by cicap

Post by Andrea Francia

Post by cicap

Post by rootkit
se proprio non può modificare il bean vorrà dire che nome e cognome
li stamperà con due h:outputText invece che uno.

Non sia mai ;)
#{user.firstName} #{user.lastName}
Grazie a Jacob Hookom...

Spiega questa citazione per favore.

Non e' una citazione ma un ringraziamento a Hookom, il creatore di
Facelets. Egli ci ha sollevato dal dover piazzare componenti
<h:outputText/> in ogni dove.

Capito grazie.

[rootkit]

Post by cicap

Post by rootkit

Post by Andrea Francia
E ma se non puo' modificare il bean che puoi fare se no?

se proprio non può modificare il bean vorrà dire che nome e cognome li
stamperà con due h:outputText invece che uno.

Non sia mai ;)

vabbeh ci siamo capiti :P

[rootkit]

Post by Andrea Laforgia
Non essere così categorico: dipende dai contesti.

se si ha in gestione un progetto bisogna prendere delle decisioni e dare
delle direttive, un po' categorici bisogna essere. certo esistono casi
particolari: se la procedura mi serve per garantire l'integrità dei dati
(trigger) allora certo che va bene, se si tratta di un job asincrono
parliamone, ma se si tratta semplicemente di scrivere codice pl/sql
anzichè java rispondo no.

Post by Andrea Laforgia
Anch'io ho creduto
per un certo tempo che fosse sempre bene mantenere la logica a un
livello meglio organizzabile, manutenibile e su cui fosse abbastanza
facile intervenire. Mi sono poi reso conto che quando c'è eterogeneità
di sistemi, spostare la logica di business su database (se non altro
come politica aziendale) non è una cattiva idea (fermi restando gli
svantaggi di cui parlavo in un altro post... s'intende). In linea di
massima sono d'accordo con te, però dipende molto dalle situazioni.

io non sono d'accordo. a meno che non sia forzata da vincoli
architetturali (in particolare di obsolescenza) non la trovo una scelta
felice, anzi direi che tende a peggiorare la situazione. non vorrei
passare per quello che vende tecnologie alla moda, ma onestamente oggi
come oggi in una infrastruttura eterogenea non pensare ad una
architettura service oriented mi sembra quasi voler fare un danno. anche
perchè fra scrivere un web service e una store procedure è più semplice
il primo (anche in java, il che è tutto dire :))

[Andrea Laforgia]

Post by rootkit
se si ha in gestione un progetto bisogna prendere delle decisioni e dare
delle direttive, un po' categorici bisogna essere. certo esistono casi
particolari: se la procedura mi serve per garantire l'integrità dei dati
(trigger) allora certo che va bene, se si tratta di un job asincrono
parliamone, ma se si tratta semplicemente di scrivere codice pl/sql
anzichè java rispondo no.

Be', sbagli nel dire no in maniera categorica. Dipende dai contesti.
Non sempre le decisioni sui progetti sono di chi ci sviluppa sopra;
molto spesso bisgona sottostare ai "capricci" del cliente. Capricci
che possono avere un fondo di ragionevolezza. Si chiamano "politiche"
:-)

Post by rootkit
io non sono d'accordo. a meno che non sia forzata da vincoli
architetturali (in particolare di obsolescenza) non la trovo una scelta
felice, anzi direi che tende a peggiorare la situazione.

Non sono d'accordo. Molto spesso il database consente di compiere
operazioni sui dati in maniera molto più performante di come faresti
altrimenti. Oracle (su cui lavoro giornalmente) è un esempio
eclatante.

Post by rootkit
passare per quello che vende tecnologie alla moda, ma onestamente oggi
come oggi in una infrastruttura eterogenea non pensare ad una
architettura service oriented mi sembra quasi voler fare un danno.

Su questo sono d'accordo, ma non vorre si facesse confusione: web
services e stored procedure non sono necessariamente alternative.

[n.n]

Post by Scorpio
Salve a tutti,
solita domanda un po' oziosa un po' seria. Tempo fa stavo revisionando il
codice di un collega e mi sono accorto che, per eseguire l'accesso ai dati,
il collega aveva fatto ricorso in modo esclusivo a delle stored procedures.
Chiestogli il perchè di questa scelta, ha risposto, un po' con l'aria di chi
la sa lunga che *deve* far capire le cosa a chi non la sa altrettanto lunga,
che l'adozione delle stored procedure per accedere ai dati è di gran lunga
la più efficiente.
Io l'ho lasciato ovviamente terminare il lavoro, però dentro la mia testa ha
cominciato a girare una rotellina, ossia un dubbio, su quando sia necessario
ricorrere a delle stored procedure e quando no.
A ben pensarci l'uso delle stored procedures ha dei vantaggi che va al di là
della pura efficienza: ad esempio mi viene in mente la possibilità di
ricompilare le stored procedures "al volo" in caso di modifica dei criteri
per estrarre un certo cursore dal database. Altro esempio che mi viene in
mente è un'operazione di "write" intesa come "insert/update": se fallisce
una insert (perchè il dato esiste già), esegui una update usando una certa
chiave.
Il problema di questo approccio è, chiaramente, la dipendenza dal "dialetto"
specifico del dbms per scrivere le stored procedures. Ma, a parte questo
inconveniente - che può essere nullo se per forza o per amore ci si lega ad
un certo vendor - quali altri svantaggi presentano le s.p ?
La butto lì - un po' provocatoriamente : se (grande SE) non ci fossero i
vari dialetti ma un linguaggio standard per ogni vendor, avrebbe ancora
senso la "rincorsa continua" ai motori di persistenza ?
Scorpio.

In linea generale avere la logica nel db e' un massacro
La logica e' molto meglio che stia nell'applicazione
per tutti i punti di vista ec cetto che per le prestazioni, che molto
raramente sono vincolanti.

ciao Nicola

--------------------------------
Inviato via http://arianna.libero.it/usenet/

[Andrea Laforgia]

Post by n.n
In linea generale avere la logica nel db e' un massacro

E' molto più che falso.

[Andrea Francia]

Post by Andrea Laforgia

Post by n.n
In linea generale avere la logica nel db e' un massacro

E' molto più che falso.

In linea generale qualsiasi affermazione è vera e falsa allo stesso tempo.

E quando si entra nello specifico che si può discutere di qualcosa di
concreto.

[Andrea Laforgia]

Post by Andrea Francia
In linea generale qualsiasi affermazione è vera e falsa allo stesso tempo.

Ma chi sei? il filosofo del gruppo?
Che significa che "qualsiasi affermazione è vera e falsa allo stesso
tempo"?
Dal mio punto di vista, che la logica di business spostata su sp sia un
"massacro" è falso e basta. E per dirlo, ho dei riferimenti concreti sotto
gli occhi, una situazione con cui ho a che fare giornalmente.

[Andrea Francia]

Post by Andrea Laforgia

Post by Andrea Francia
In linea generale qualsiasi affermazione è vera e falsa allo stesso tempo.

Ma chi sei? il filosofo del gruppo?
Che significa che "qualsiasi affermazione è vera e falsa allo stesso
tempo"?
Dal mio punto di vista, che la logica di business spostata su sp sia un
"massacro" è falso e basta. E per dirlo, ho dei riferimenti concreti sotto
gli occhi, una situazione con cui ho a che fare giornalmente.

n.n non ha detto che è vero sempre. Ha detto che è vero solo in linea
generale. Che equivale a non dire niente.

Finché si parla "in linea generale" l'affermazione di n.n. non puo'
essere ne verificabile ne confutabile.

Anche se tu porti esempi concreti uno potrebbe sempre dire che
potrebbero essere casi isolati e l'affermazione non verrebbe confutata.

Di contro l'affermazione non è neanche verificabile. Cosa vuol dire in
linea generale? La maggior parte delle volte? Chi ha un'esperienza
obiettiva e non soggettiva di quello che succede la maggior parte delle
volte.

[rootkit]

Post by Andrea Francia
n.n non ha detto che è vero sempre. Ha detto che è vero solo in linea
generale. Che equivale a non dire niente.

scusami eh, ma se hai voglia di buttarla nel nonsense dillo prima.
in linea generale significa in linea generale, se non lo capisci bisogna
te lo faccia spiegare da qualcuno che ha tempo e voglia di farlo.

[Andrea Francia]

Post by rootkit

Post by Andrea Francia
n.n non ha detto che è vero sempre. Ha detto che è vero solo in linea
generale. Che equivale a non dire niente.

scusami eh, ma se hai voglia di buttarla nel nonsense dillo prima.
in linea generale significa in linea generale, se non lo capisci bisogna
te lo faccia spiegare da qualcuno che ha tempo e voglia di farlo.

Per me una affermazione in linea generale non serve a niente in una
discussione.

[Pablo Xon]

Post by Andrea Francia
Per me una affermazione in linea generale non serve a niente in una
discussione.

Però scusa, senza polemica, scrivi:
- ""in linea generale" l'affermazione [...] non puo' essere ne
verificabile ne confutabile";
- "in linea generale qualsiasi affermazione è vera e falsa allo stesso
tempo" [affermazione logicamente non corretta, ma non entriamo in
ulteriori dettagli];
- "se tu porti esempi concreti uno potrebbe sempre dire che potrebbero
essere casi isolati e l'affermazione non verrebbe confutata".

Mi sembra che si stia un po' slittando verso il paralogismo (o meglio:
nel sofismo puro ;) ): l'affermazione generale non è valida perché manca
di dettagli, i dettagli/casi non sono validi perché riguardano solo
parti dell'affermazione.
...mah?!...

Di solito, senza voler nulla insegnare a nessuno, prima si osservano i
fatti, i dettagli, poi da questi si ipotizzano delle affermazioni
(generali, diverso da assolute) che vanno verificate con altri fatti. Se
questi non confutano l'affermazione generale la si ritiene valida, sino
a prova contraria.

:)

Ciao,
Paolo

[Andrea Francia]

Post by Pablo Xon
Di solito, senza voler nulla insegnare a nessuno, prima si osservano i
fatti, i dettagli, poi da questi si ipotizzano delle affermazioni
(generali, diverso da assolute) che vanno verificate con altri fatti. Se
questi non confutano l'affermazione generale la si ritiene valida, sino
a prova contraria.

Perché deve essere ritenuta valida?
Tocca a chi fa un affermazione di dimostrare se è valida o meno.

Gli altri possono solo dire: "Potrebbe avere ragione oppure no".

Io posso dire che su Urano c'e' vita, ma gli Uraniani si nascondo i
terrestri perché gli stiamo sul culo.

La puoi verificare? No.
Mi puoi smentire? No.

La prendi per vera fino a prova cotraria? Spero di no.

[Davide Consonni]

Post by Andrea Francia
Io posso dire che su Urano c'e' vita, ma gli Uraniani si nascondo i
terrestri perché gli stiamo sul culo.

che stronzi sti uraniani ...

[Pablo Xon]

Post by Andrea Francia
Perché deve essere ritenuta valida?
Tocca a chi fa un affermazione di dimostrare se è valida o meno.

Hai dimenticato un "piccolo" dettaglio: i fatti su cui ci si è basati
per formulare l'ipotesi ;)

Post by Andrea Francia
La puoi verificare? No.
Mi puoi smentire? No.

Perché è un'opinione, non un'ipotesi :)
La differenza? La mancanza di dati, se fossero presenti potrei
verificarla e, eventualmente, smentirla.

Ciao,
Paolo
P.S.: se andiamo un po' più OT gli Uraniani ce li lasciamo alle spalle... :D

[Andrea Francia]

Post by Pablo Xon

Post by Andrea Francia
La puoi verificare? No.
Mi puoi smentire? No.

Perché è un'opinione, non un'ipotesi :)
La differenza? La mancanza di dati, se fossero presenti potrei
verificarla e, eventualmente, smentirla.

Sì è un opinione. E' un opinione formulata come se fosse un'affermazione.

Il mio punto è che non ha senso trattarla come un'affermazione.

Secondo me ha poco senso dire: "ha ragione fino a prova contraria"
oppure dire: "è falsa".

[Andrea Francia]

Concluderei l'OT citando Palmiro Cangini:

"... e con questo cosa voglio dire?
Non lo so! Pero' c'ho ragione!
E i fatti mi cosano!"

[Pablo Xon]

Post by Andrea Francia
"... e con questo cosa voglio dire?
Non lo so! Pero' c'ho ragione!
E i fatti mi cosano!"

:D

[rootkit]

Post by Andrea Francia
Perché deve essere ritenuta valida?
Tocca a chi fa un affermazione di dimostrare se è valida o meno.
Gli altri possono solo dire: "Potrebbe avere ragione oppure no".
Io posso dire che su Urano c'e' vita, ma gli Uraniani si nascondo i
terrestri perché gli stiamo sul culo.
La puoi verificare? No.
Mi puoi smentire? No.
La prendi per vera fino a prova cotraria? Spero di no.

mi indichi per favore dov'è che è stata fatta una affermazione così
stupida da meritare questo paragone? la frase da cui è partita questa
(imho folle) discussione era assolutamente pertinente, si può essere o
meno d'accordo ma ti ricordo che tu non ti sei posto il problema di
confutarla, bensì il tuo problema è stato discutere che quella
affermazione era stata fatta "in linea generale".

[Andrea Francia]

Post by rootkit

Post by Andrea Francia
Perché deve essere ritenuta valida?
Tocca a chi fa un affermazione di dimostrare se è valida o meno.
Gli altri possono solo dire: "Potrebbe avere ragione oppure no".
Io posso dire che su Urano c'e' vita, ma gli Uraniani si nascondo i
terrestri perché gli stiamo sul culo.
La puoi verificare? No.
Mi puoi smentire? No.
La prendi per vera fino a prova cotraria? Spero di no.

mi indichi per favore dov'è che è stata fatta una affermazione così
stupida da meritare questo paragone?

L'esempio degli Uraniani è partito perché qualcuno ha detto che le
affermazioni sono vere finché non sono smentite. Non c'entra niente con
la tua frase.

Post by rootkit
la frase da cui è partita questa
(imho folle) discussione era assolutamente pertinente, si può essere o
meno d'accordo ma ti ricordo che tu non ti sei posto il problema di
confutarla, bensì il tuo problema è stato discutere che quella
affermazione era stata fatta "in linea generale".

Ho mai detto che la tua frase non era pertinente?

Se controlli io ho risposto al post successivo che diceva riguardo alla

Post by rootkit
E' molto più che falso.

Ha poco senso falsificare un'opinione in quanto le opinioni non sono
falsificabili.

E in piu' senza argomentazioni non poneva neanche una base per
confrontare le due opinioni contrapposte.

[rootkit]

Post by Andrea Francia

la frase da cui è partita questa (imho folle) discussione era
assolutamente pertinente, si può essere o meno d'accordo ma ti ricordo
che tu non ti sei posto il problema di confutarla, bensì il tuo
problema è stato discutere che quella affermazione era stata fatta "in
linea generale".

Ho mai detto che la tua frase non era pertinente?

ma non era mia la frase!

scusa la franchezza, a questo punto il dubbio se ci sei o ci fai mi viene...

[Andrea Francia]

Post by rootkit

Post by Andrea Francia

la frase da cui è partita questa (imho folle) discussione era
assolutamente pertinente, si può essere o meno d'accordo ma ti
ricordo che tu non ti sei posto il problema di confutarla, bensì il
tuo problema è stato discutere che quella affermazione era stata
fatta "in linea generale".

Ho mai detto che la tua frase non era pertinente?

ma non era mia la frase!

Scusa, scusa, mi sono confuso tra rootkit e n.n.

[Pablo Xon]

Post by Andrea Francia
L'esempio degli Uraniani è partito perché qualcuno ha detto che le
affermazioni sono vere finché non sono smentite.

Scusa se te lo faccio notare ma nessuno ha detto questa cosa.
Sempre che tu non prenda un pezzo di frase, ne togli dei pezzi, ne
incolli altri col risultato di ottenere quello che vuoi...

E, te ne prego, non replicare citando solo metà del mio discorso ;)
Parlare di ipotesi, tesi e dimostrazione è ben diverso dal parlare
esclusivamente di ipotesi.

Ciao,
Paolo

[Andrea Francia]

Post by Pablo Xon

Post by Andrea Francia
L'esempio degli Uraniani è partito perché qualcuno ha detto che le
affermazioni sono vere finché non sono smentite.

Scusa se te lo faccio notare ma nessuno ha detto questa cosa.

Scusate forse ho capito male.

Post by Pablo Xon
Sempre che tu non prenda un pezzo di frase, ne togli dei pezzi, ne
incolli altri col risultato di ottenere quello che vuoi...
E, te ne prego, non replicare citando solo metà del mio discorso ;)

Cercherò di non farlo più.

Post by Pablo Xon
Parlare di ipotesi, tesi e dimostrazione è ben diverso dal parlare
esclusivamente di ipotesi.

Non ce la faccio piu' a fare metadiscussioni. Lo so che ho cominciato
io. Pero' non ci sto più capendo niente e quindi cerco di non proseguire
piu'.

Post by Pablo Xon
Ciao,
Paolo

[Alessandro Cara]

Post by Andrea Francia

Post by Pablo Xon

Post by Andrea Francia
L'esempio degli Uraniani è partito perché qualcuno ha detto che le
affermazioni sono vere finché non sono smentite.

Scusa se te lo faccio notare ma nessuno ha detto questa cosa.

Scusate forse ho capito male.

Post by Pablo Xon
Sempre che tu non prenda un pezzo di frase, ne togli dei pezzi, ne
incolli altri col risultato di ottenere quello che vuoi...
E, te ne prego, non replicare citando solo metà del mio discorso ;)

Cercherò di non farlo più.

Post by Pablo Xon
Parlare di ipotesi, tesi e dimostrazione è ben diverso dal parlare
esclusivamente di ipotesi.

Non ce la faccio piu' a fare metadiscussioni. Lo so che ho cominciato
io. Pero' non ci sto più capendo niente e quindi cerco di non proseguire
piu'.

Ma dai. Quella degli uraniani. Non so chi l'ha scritta.
Era la cosa piu' profonda che ho letta. Hanno tutte le ragioni di
nascondersi agli umani soprattutto se gli umani sono esperti java. ;<))))))

[Pablo Xon]

Post by Andrea Francia
Ha poco senso falsificare un'opinione in quanto le opinioni non sono
falsificabili.

Un P.S. per mia curiosità personale: :)
mi spieghi la differenza tra opinione e ipotesi (escluso l'ambito di
applicazione)?

Ciao,
Paolo

[Andrea Francia]

Post by Pablo Xon

Post by Andrea Francia
Ha poco senso falsificare un'opinione in quanto le opinioni non sono
falsificabili.

Un P.S. per mia curiosità personale: :)
mi spieghi la differenza tra opinione e ipotesi (escluso l'ambito di
applicazione)?

Secondo me l'opinione è una cosa che uno pensa essere vera senza avere
necessariamente prove certe che ne dimostrino la veridicità.

Credo che ci siano usi diversi della parola 'ipotesi'.

Delle volte si usa ipotesi come sinonimo di teoria.

Altre volte si usa 'ipotesi' per indicare un'affermazione dalla quale,
se fosse vera, ne conseguono altre altre.

Post by Pablo Xon
Ciao,
Paolo

[n.n]

Post by Andrea Laforgia

Post by n.n
In linea generale avere la logica nel db e' un massacro

E' molto più che falso.
--
questo articolo e` stato inviato via web dal servizio gratuito

Rispondo qua ma ho letto tuttta la linea filosofica.


Accetto le critiche alla frase "In linea generale" poiche' e' poco
scientifica.

Modific l'affermazione:

Nella maggiore parte di ambiti applicativi scrivere parti di logica dentro
il database tramite stored procedure e similari e' architetturalmente
scorrretto e piu' gli applicativi sono grossi , complressi e distribuiti ,
piu' e' diventa un massacro per il team che ci lavora

1.
Si vincola l'applicazione a una tipo di supporto dati, in questo caso
database, il che e' una limitazione forte perche se si volesse applicare la
BL a un altro tipo di dati non si dovrebbero replicare intere parti di
logica per gestire altri dati. Scorrettissimo.

2
Purtroppo oggi ci si vincola addirittura a un vendor.
Scorrettissimo.

3.
I Database per loro natura non sono linguaggi di programmazione e quindi
sono molto ma molto inferiori ai linguaggi OOP moderni in quanto ad
architettura delle applicazioni, manutenibilita', leggibilita'.
portabilita', integrabilita', eleganza.
Qquindi e' scorrettissimo scegliere di scrivere in un DB la logica se non
c'e' una esigenza sopecifica che ne giustifichi l'tilizzo .

4.
L'unico motivo per cui si puo' / si deve scrivere in un db sono le
prestazioni.
Poiche' pero' nel 90, anche 99% degli applicativi le prestazioni non sono un
problema si puo' dire che quasi sempre e' sconveniente scrivere logica in un
DB.
Aggiungiamo che poiche' le prestazioni negli anni stanno salendo
vertiginosamente, si puo' pensare che fra altri anni si avranno prestazioni
infinite ( tempi nulli di IO). A quel punto le stored procedure si
estingueranno come si sono estinte le schede perforate.




Il dato 90 , 99% non ha una fonte, e' una mia statistica personale che ho
verificato nella mia esperienza e che ecomunque e' supportata dal fatto che
le prestazioni crewscono cosi' tanto negli anni che quello che era lento
20/30 anni fa oggi ha avuto un aumento di X% gfrazie all'HW.
Qualora si fosse scritto 20 anni fa un progetto in Database per avere un
aumento di Y% potremmo facilmente verificare che X%>>Y%, quindi salvo casi
eccezionali non e' l'utilizzo dei DB come linguaggi che si risolve il
problema prestazionale e e prestazioni sono un falso problema.

Aggiungo per concludere che di solito java non viene utilizzato ancora per
applicazioni ad altissime prestazioi quali i videogames e quindi dire che in
java il problema prestazionale non e' molto sentito e' ancora piu' vero
rispetto ad altre piattaforme.

Ciao a tutti
Nicola













--------------------------------
Inviato via http://arianna.libero.it/usenet/