Newsgroup: it.lavoro.informatica
Titolo: Stored Procedure e Trigger

Ciao a Tutti,

    mi piacerebbe discutere con voi dell'utilizzo di Stored Procedure e Trigger 

    Da un po' di tempo a questa parte le sto rivalutando parecchio nelle situazioni in cui debbo garantire l'integrità della Bussiness Logic in situazione in cui le scritture avvengono da "fonti" diverse.

    Cosa ne pensate?



Ciao

  Francesco





Che e' un suicidio implementare business logic non banale tramite SP.



Se avete webservice di qualunque natura, ecco quelli dovrebbero essere il punto di integrazione tra le varie "fonti", non le SP o i trigger.



cioè  tipoooooo mi son fatto na sega con la figacciona del festival, 

cosa ne pensate?



...e lo chiedi qui? Qui nessuno ha mai fatto una applicazione che vada 

al dilà dei giochini, hai sbagliato ng.



-- 

Quando la dittatura è un dato di fatto, la rivoluzione diventa un diritto.

(Victor Hugo)






bastona delta, bastonali, che se lo meritano !!



--

Ciarlatani








 Che e' un suicidio implementare business logic non banale tramite SP.



Condivido solo in parte. Io ho lavorato su sistemi in cui la b.l. era implementata a quel modo e funzionavano perfettamente. Certo e` che sei limitato dai linguaggi che puoi usare; con Oracle, PL/SQL e` un linguaggio limitatissimo. Dipende dalla complessita` di un sistema. Scrivere la b.l. in Java e delegare al DB solo lo storage dei dati non e` una scelta sbagliata.






E che ne sai tu.





I trigger servono per risolvere situazioni particolari

Come hai scritto non hanno niente a che fare con la B.L.,sono un 

qualcosa di interno ad un progetto di B.L.

Le stored procedure,ma piu che altro i package (raccolta di stored 

procedure  se si usa oracle ad esempio) possono essere utili anche per 

le performance.

L'unico neo di tutto questo è che non è portabile,cambi db e re 

implementare il tutto puo essere abbastanza complicato.

Invece con   i soli comandi sql la portabilità e' piu facile.

Personalmente non amo implementare tutta la B.L. in stored procedure in 

quanto non portabile e meno flessibile rispetto  un linguaggio 

convenzionale come C++ o java.

Diciamo preferisco vedere le stored procedure come uno strato interno 

alla B.L.











Con ms sqlserver si possono scrivere le sp anche in c#, quindi è 

possibile mantenere la complessità dentro il db.




 Condivido solo in parte. Io ho lavorato su sistemi in cui la b.l. era implementata a quel modo e funzionavano perfettamente. Certo e` che sei limitato dai linguaggi che puoi usare; con Oracle, PL/SQL e` un linguaggio limitatissimo. Dipende dalla complessita` di un sistema. 



Curiosità: io non conosco Oracle; so per certo che SQLServer consente l'impiego delle managed stored procedures (leggi: le puoi scrivere con qualsiasi linguaggio che faccia riferimento a .NET e poi integrarle) e che in PostgreSQL puoi usare linguaggi esterni - io ho usato Python - oltre al linguaggio SQL integrato. In Oracle non c'è la possibilità di usare linguaggi, anche di scripting, esterni?



-- 

Ciao!

Luca



La domanda è interessante.

Io penso che non c'è una risposta universale, nel senso che come al

solito la soluzione migliore dipende dal contesto.



Implementare tutta la business logic nelle sp può essere una buona

scelta nelle situazioni in cui un'operazione di crud coinvolge

l'uso di molte tabelle.

Insomma, se per inserire un record in una tabella, o modificare un

record o cancellarlo, devo fare operazioni analoghe in altre tabelle

logicamente correlate, allora a mio avviso è da prendere in buona

considerazione l'uso delle sp, ossia mettere tutte queste operazioni

in un'unica sp.



Naturalmente non è obbligatorio, puoi anche eseguire N query lato

server in un'unica transaction, ma mi sembra chiaro che usare una sp

avrebbe molti vantaggi.







Se invece l'operazione di persistenza è solo una, e devi mettere altra

business logic che non necessita di connessione al db, allora

al contrario le sp non le vedo tanto bene, a quel punto direi che

conviene implementare la logica nel server.









A me anni fa è capitato di lavorare ad un portale in cui si era

scelto di implementare la business logic nelle sp, e in quel

caso la scelta mi era sembrata pertinente perché era un portale

web per la gestione di un magazzino, e le singole operazioni di

persistenza coinvolgevano più tabelle.



Per non parlare poi della manutenibilità: se la business logic

doveva essere modificata, spesso non era necessaria alcuna

modifica al codice java, bastava cambiare e ricompilare la sp,

testare e avevi la modifica (non sempre ovviamente, se si

cambiava il numero o il tipo di parametri della sp bisognava

modificare di conseguenza il codice java, ma se i parametri

non cambiavano il codice java andava già bene così).







Peraltro, come ha sottolineato enoquick, mettere la business

logic nelle sp può essere molto problematico in quei progetti che

devono andare su basi dati diverse, perché ogni db ha la sua

sintassi per le sp, e lì questo approccio lo vedo molto male.



Io conosco Oracle, Sql Server e MySql, e in questi tre db le

sp si scrivono in modo differente.








 



ti chiedo una precisazione: cosa intendi quando dici che le

scritture avvengono da fonti diverse?

Puoi essere più chiaro?






Per non parlare anche di controllare le dipendenze tra gli oggetti lato 

db in caso di manutenzioni a pezzi di db usati parecchio.

Se devi cercare solo nel db è una cosa, se ti devi mettere anche a 

verificare lato client chi usa cosa e come, auguri...









attualmente dove sono impiegato (PA) mi occupo principalmente di 

scrivere codice PL/SQL oltre che fare da DBA,



nel progetto TUTTA la B.L. si trova nelle SP.



all'inizio quando sono entrato nel progetto pensavo fosse una fesseria, 

oggi a distanza di 3 anni, capisco le ragioni che hanno spinto ad un 

simile approccio.



per modifiche di BL o bug che non comportano il cambiare i parametri (la 

firma delle SP), ZERO deploy, una modifica lato SP e vai. tempo della 

messa in produzione meno di mezz'ora. se invece era su java, tra 

modifica , commit, rifare l'EAR richiedere le autorizzazione per il 

deploy nei vari ambienti e in prod, ci passa almeno una settimana (dove 

lavoro i deploy in prod sono schedulati una volta alla settimana, in 

casi URGENTI in giornata).



non solo, ma considerando che il committente ti cambia la logica ogni 2 

per 3, è più facile stargli dietro tramite SP che lato java.



poi certo il linguaggio PL/SQL è limitato (e gli sto facendo un 

complimento).

per creare array, liste o altro che sia leggermente un più complesso di 

un cursore, sputi sangue.



Ciao



Proprio per questo,la scarsa portabilità ed una progettazione non 

proprio OO come i linguaggi OOP,preferisco le SP inglobate nelle BL più 

che facciano da BL.

In questo modo,oltre ad avere una vera interfaccia OOP, in caso di 

porting ad un altro DB si hanno meno problemi.

Mal che vada si riscrivono le SP in linguaggio convenzionale.







QUOTO TUTTO E CONCORDO SU TUTTO.

Finalmente su questo ng si affaccia uno che non fa lo smanettone ma si 

confronta con la REALTÀ TUTTI I GIORNI.

VORREI RICORDARE CHE IL PL/SQL NON È AD OGGETTI E VIEN DA SE CHE È MOLTO 

SIMILE AL COBOL. Ma non volevo infierire a tal punto da farvi male! SDEEENG!

Bamboccioni dell'ostia.



 simile approccio.



Comprendo le motivazioni che hanno spinto a questa scelta, e probabilmente nel vostro caso era quella corretta. Io sono agnostico: se la situazione lo suggerisce, perché non integrare tutta la BL nella base dati?



Tuttavia io penso che la situazione ideale sia distribuita. Ci sono situazioni in cui viste logiche e stored procedures sono maledettamente comode e vanno usate; ci sono situazioni in cui si è più comodi e veloci impiegando uno strato software superiore. Io credo che la valutazione vada opportunamente fatta di volta in volta.



-- 

Ciao!

Luca


 Qualcosa di simile alle managed stored procedures in SQLServer?



aaaaaa bhe! se hai mollato mysql per quella merda allora si che sei a posto.

Quella merda era valida quando si chiamava sybase, come al solito l'ha 

preso in mano ms ed è diventato na bella merda!



ma quando vi scrollate di dosso la merda ms specialmente come server?



 Puoi essere più chiaro?



Da ambienti diversi e programmi diversi che condividono lo stesso DB.

Per alcuni è comodo usare webservice per altri molto meno: la scelta di usare SP e TR dovrebbe evitare di disperdere la logica in mille posti.



Ciao

  Francesco


 aaaaaa bhe! se hai mollato mysql per quella merda allora si che sei a posto.



No. La valutavo come alternativa, ma all'epoca aveva talmente tante mancanze - ad esempio, non aveva proprio le stored procedures - che ho pensato bene di mollarli a favore di PostgreSQL. Oggi, se chiedono a me, la scelta è:

- hai bisogno di una veloce archiviazione locale, con pochi dati? SQLite è la tua scelta;

- hai bisogno di distribuire dati e magari di scalare nel tempo? PostgreSQL.



Poi capita che ci siano ragioni di vario genere per obbligare a SQLServer. Che, detto inter nos, da qualche versione va decisamente meglio - è che come il solito ci vuole un buon DBA (*)



(*) Una volta, in un progetto grosso che coinvolgeva diversi dati anche incrociati, abbiamo installato una versione Express di SQL Server in un PC non nuovissimo; lo scopo era: se gira decentemente qua, nei mega server che ci metteranno a disposizione, con la versione Full di SQL Server, andrà come un caccia (nota: noi non avevamo possibilità di amministrare i DBMS). Abbiamo caricato un paio di decine di milioni di record per tabella, e abbiamo verificato il decadimento di prestazioni (trascurabile). Bene, messa in produzione, sui server loro, andava da piangere. La cosa divertente è che staccata la loro base dati, così com'era, e agganciata al famoso PC, andava splendidamente! Ovviamente, un report di prestazioni ha tacitato tutte le lamentele del cliente di allora.



-- 

Ciao!

Luca


 Allora anche a te domando: non ci sono in Oracle alternative a PL/SQL?



guarda non me ne sono mai interessato, quello che posso dirti è che in 

ambito oracle pl/sql è uno standard de facto, ma penso di si, java 

sicuramente.

In db2 invece puoi scrivere le sp in qualunque linguaggio compreso java, 

c, COBOL, i piu usati oltre all'sql(tipo pl/sql) naturalmente.



On Monday, 15 February 2016 19:53:18 UTC, Luca Menegotto  wrote:



[...] In Oracle non c'è la possibilità di usare linguaggi, anche di scripting, esterni?



Sinceramente non lo so. Io ho sempre e solo usato PL/SQL. Diciamo che se devo usare dei linguaggi esterni, tanto vale affidare la business logic ad un tier scritto in Java. 






 se la situazione lo suggerisce, perché non integrare tutta la BL nella base dati?



Infatti non c'e` alcun problema, a parte il fatto che ci si limita ad usare, come nel caso di Oracle PL/SQL, un linguaggio fondamentalmente procedurale, quindi senza i vantaggi dell'OOP. Esistono poi vantaggi non indifferenti quando si usano funzioni specifiche del db. Ad esempio, in Oracle c'e` il comando MERGE che racchiude in se` un numero tale di funzionalita` che implementarle singolarmente, in uno strato di B/L esterno, sarebbe sicuramente meno efficiente. Quando lavori con tanti dati, la differenza di sente.




 - hai bisogno di distribuire dati e magari di scalare nel tempo? PostgreSQL.



Per distribuire e scalare, OGGI, si usano db NoSQL.


 Poi capita che ci siano ragioni di vario genere per obbligare a SQLServer. 



Il cazzone trollone, come sempre, non sa quel che dice, e parla dal fondo della sua ignoranza e incompetenza. Si`, ci sono ottime ragioni per usare SQL Server, ed una e` che SQL Server e` un ottimo RDBMS.




 testare e avevi la modifica



Purtroppo non e` sempre cosi` semplice. Con Oracle, per esempio, i package vengono invalidati, per cui devi comunque riconnetterti.


 deploy nei vari ambienti e in prod, ci passa almeno una settimana



Questo, pero`, e` un problem vostro, non di Java.


 Per distribuire e scalare, OGGI, si usano db NoSQL



Ce ne sono applicazioni interessanti, che sto studiando. Per il mio livello di competenza attuale - ma la parte NoSQL sta crescendo), mi sembra che siano due insiemi differenti con un'intersezione ampia; intendo: mi sembra ci siano situazioni in cui è assolutamente preferibile un DBMS NoSQL, altre in cui è preferibile un DBMS SQL relazionale.



Però, magari, non ho ancora avuto la mia epifania!



-- 

Ciao!

Luca



vero



ma sai come vanno le cose, ti dicono oggi, che dovevi fare una cosa 

ieri, e che doveva essere pronta per la scorsa settimana :)



Ciao




 Qualcosa di simile alle managed stored procedures in SQLServer?



finora ho sempre e solo utilizzato PL/SQL

so però che puoi interagire direttamente con Java tramite quello che 

oracle definisce Java Stored Procedure



da quel che leggo, pochi lo utilizzano e non conosco le performance.



Ciao


 casi URGENTI in giornata).



io nel medio/lungo periodo questo approccio lo trovo devastante.

è facile (anzi, è sicuro) abbandonarsi all'idea che il repository dei

sorgenti sia lo stesso database: se va bene c'è quello di dev che riflette

lo stato dello sviluppo, ma più probabilmente l'unica immagine consistente

è quella di produzione e solo perché c'è il dato di fatto che funziona. in

pratica si allinea la procedura di rilascio all'emergenza, cioè tutto

viene fatto come se fosse della massima urgenza. se ci sono più

sviluppatori il rischio di regressioni è altissimo. non c'è storico di chi

ha fatto cosa, non sai come una fix è stata fatta se non ne sei l'autore

(e a patto tu abbia buona memoria).



sinceramente non vedo un solo motivo, neanche uno, per considerare

valido questo approccio.



peraltro non capisco questo discorso dei tempi di rilascio biblici 

dell'applicativo. a fare una build a diritto dal master e buttarla in 

produzione non impieghi mica delle ore, il tempo ci vuole eventualmente 

per i controlli e l'iter autorizzativo che dall'altra parte salti a piè 

pari. 





Oracle supporta nativamente solo PL/SQL.

Poi si possono chiamare routine in java e C.

Non mi risulta altro.





Il PL/SQL ha preso da Ada,non da COBOL.

E non e' simile al COBOL.




 pari.



Personalmente uso un CVS anche per le SP



Ciao

  Francesco


 casi URGENTI in giornata).



E per aggiungere a quanto altri hanno gia' scritto su questa pratica, secondo me cogliona ;), ma allora tanto vale usare le JSP. Fanno abbastanza ribrezzo nel 2016, ma piuttosto di PL/SQL (se e' solo questo il motivo ovviamente)...modifichi a caldo e via.



Non ha alcun senso in ogni caso.



abbiamo un repository svn anche per le SP, vero che lo devi 

sincronizzare a mano, (copia del source a manina, oracle di suo non lo 

permette :( ), ma funziona tale e quale ad un versioning di qualsiasi 

altro progetto.



si sviluppa in sviluppo / collaudo (per le esigenze di dati allineati), 

e si passa in collaudo, per la produzione si copia prima i sorgenti su 

svn (quelli attuali di produzione) e poi si fa il passaggio.



per i tempi, essendo una PA, ha tutto un suo mondo, ahimè, dettato anche 

da una questione di chiamiamola burocrazia.



Ciao



Sono stato il primo quando si è formato il team ad avere i brividi su 

come si voleva strutturare il progetto (premetto che anche gli altri 

progetti di area sono simili come architettura)



poi man mano che ci lavoro, ne vedo i benefici, anche se la tecnologia è 

limitatissima.



nel progetto, ci si interfaccia con più db e diverse fonti di dati, 

(schemas, altri dbms, webservices, filesystem)

e avere tutto gestibile da un unica fonte e con le stesse modalità, lo 

vedo come un vantaggio.



certo interrogare un webservice, interagire con filesystem, chiamare 

DB2, tutto tramite PL/SQL è stato un bagno di sangue, ma ho anche avuto 

i miei momenti di soddisfazione.



ma soprattutto sapere se qualcosa è andato storto, sapere immediatamente 

dove intercettare il problema, e aggirarlo in modo indolore.



faccio un esempio



è capitato che c'è stato un bug che scriveva in maniera errata dei dati 

di produzione (contabili), quando ci siamo accorti dell'errore (è sceso 

odino incazzato come una iena) la soluzione che si prospettava era 

quella di chiudere produzione fino al risolvimento del bug.

invece avendo tutta la BL su oracle, abbiamo mantenuto l'operatività, ma 

abbiamo deviato l'errore andando a scrivere su file di log e non facendo 

inserire l'errore in produzione, abbiamo potuto in questo modo gestire 

l'emergenza con calma e valutare il da farsi.



gli utenti hanno potuto continuare a lavorare e non si sono accorti di 

nulla (a parte una piccola chiusura di 2 ore per mettere in piedi lo 

switch).



Ciao


 Non ha alcun senso in ogni caso.



Scusa ma tu hai mai usato delle SP?

A parte il fatto che sono diversi ordini di grandezza più veloci della JSP la differenza è che esse funzionano indipendente da chi manipola i dati.



Non tutto il mondo è solo web...



Ciao

  Francesco


 ma sai come vanno le cose[...]



Di nuovo, le cose andranno cosi` dove lavori tu, non di certo dove lavoro io.




 A parte il fatto che sono diversi ordini di grandezza più veloci della JSP



Dal fatto che tu stia confrontando Stored Procedure e pagine JSP si evince che non hai capito un cazzo ne` del mondo web, ne` di quello non web.



Puoi annidare il PLSQL nel C con il pre-compilatore pro-C e le librerie native Oracle: alla fine viene generato un file C da compilare con gli altri


 Non tutto il mondo è solo web...



Ma che c'entra. Si parlava solamente di deploy a caldo, tutto il resto non era in discussione.


 switch).



ah ecco. Ma possibile che non ti accorgi di dove sta il problema? Avete interrotto il servizio, modificato il codice e deployato la nuova modifica in due ore. 



Tutto questo si puo' fare in Java come in PL/SQL, se non lo fate in Java e' solamente perche' avete problemi grandi come una casa nel vostro ciclo di rilascio. Oppure esistonno stupide norme burocratiche che, non si sa per quale ragione, vengono saltate solo perche' il linguaggio e' PL/SQL invece di Java.


 Puoi annidare il PLSQL nel C con il pre-compilatore pro-C e le librerie native Oracle: alla fine viene generato un file C da compilare con gli altri



Non e` quel che si vuol fare, pero`. Pro*C e` semplicemente SQL Embedded (che non verra` piu` usato da almeno un millennio), mentre quel che si vuol fare e` usare un linguaggio alternativo a PL/SQL.




 se non lo fate in Java e' solamente perche' avete problemi grandi come una casa nel vostro ciclo di rilascio. Oppure esistonno stupide norme burocratiche che, non si sa per quale ragione, vengono saltate solo perche' il linguaggio e' PL/SQL invece di Java.



Concordo.





non dico che lo stesso non si poteva fare in altro modo.



dico solo che in quel caso la risoluzione non era di 2 ore ma ci sono 

voluti 10 gg per risolvere il problema (non era un semplice bug, ma 

proprio di flusso, veniva calcolato in modo diverso per determinate 

casistiche che dall'analisi non erano state prese in considerazione)

ora o si chiudeva per 2 settimane (tra riunioni e analisi della 

casistica, sviluppo, test, autorizzazioni varie e bonifiche dei dati), o 

avrebbero continuato a scrivere in modo errato fino alla messa in 

produzione con conseguenza di dati sputtanati in prod, oppure la 

soluzione che al momento ci è sembrata più idonea e che non ha 

comportato ne interruzione, ne inconsistenza di dati, con una bonifica 

sul pregresso relativamente semplice.





Ciao






 voluti 10 gg per risolvere il problema



No! La soluzione la sapete voi, ma se quella di rigirare su log era buona, allora si poteva fare in Java tranquillamente. PL/SQL non ha offerto alcun vantaggio.



Oppure vi ci vogliono dieci giorni di test e rilascio anche per fare un redirect su file in Java?


 





a proposito di array:



http://www.tutorialspoint.com/plsql/plsql_arrays.htm




io non ho mai lavorato con l'sql per le liste o gli array, e stavo

curiosando quel link.



Comunque sono d'accordo con te che in questo caso sia meglio

un linguaggio come il java. 





Rispondi a Cicap idiota, è lui che ha presentato l'alternativa 

intelligente (quella di camblare l'accesso al db nelle jsp per rendere 

il deploy più veloce).







Come che c'entra, gli hai detto te di non usare le sp perché tanto 

l'equivalente del corpo delle sp lo si può sbattere in chiaro nelle jsp 

a colpi di sql dinamico. E giustamente ti han fatto notare che il tsql 

in chiaro eseguito di continuo è più lento di una sp che viene compilato 

dal db engine e rimane li a disposizione con il suo bel piano di 

esecuzione già pronto.






On 16/02/2016 19:35, AleTV wrote:



[...]



Zitto, rincoglionito. Te l'ho gia` consigliato una volta. Non farmi 

ripetere.



-- 

4ndre4

"The use of COBOL cripples the mind; its teaching should, therefore, be 

regarded as a criminal offense." (E. Dijkstra)

"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 

http://goo.gl/1nrkkX





Imbecille, rispondi invece, pesta merde che non sei altro.




 Imbecille, rispondi invece, pesta merde che non sei altro.



Capisco che il culo ti fa ancora male, ma dovresti sfogarti in maniera 

piu` sana. LOL :) che idiota. Io non devo rispondere a niente, COGLIONE.





E allora che rispondi a fare, essere inutile.




On 16/02/2016 20:24, AleTV wrote:



[...]



Stai zitto, imbecille.




non ho detto che la soluzione è stata quella del file di log.



se devo entrare nel merito della problematica, lo faccio tanto per 

chiarire , poi non ho mai detto che è stata adottata LA soluzione, ma 

quella che a noi in quel contesto sembra la più logica.





Contesto:

gli utenti hanno la possibilità di inserire le note spese e delle 

richieste che gli vengono pagate con la busta paga.

ora il 90% degli utenti inserisce questi rimborsi l'ultima settimana 

disponibile.



il sistema prende, controlla, verifica e scrive in contabilità pronte 

per essere elaborate per la busta paga.



Anomalia :

l'errore che c'è stato è dettato da una regola.

gli utente se hanno lavorato fuori sede hanno diritto ad un buono pasto 

forfettario in base a delle regole, ore lavorate, fascie orarie, 

accompagno ecc..



proprio l'accompagno ha scaturito l'anomalia.



la regola vuole che se il dipendente accompagna un dirigente, lo stesso 

percepirà il forfettario del buono allo stesso importo del dirigente, 

che è il doppio del dipendente.



quindi il sistema aggangia il lavoro fuori sede del dipendente al 

dirigente se questo lo accompagna, per tutta la durata del lavoro del 

dirigente.



l'anomalia si è verificata quando il dipendente rientra PRIMA del 

dirigente, calcolando un importo errato (continua a ricevere il 

forfettario e lo riceve doppio), o se il dipendente invece del 

forfettario inserisce la nota spesa del pasto.



l'anomalia è una casistica non prevista dalle regole e a comportato un 

analisi per capire come comportarsi.



ora, dato che ci siamo accorti di questo l'ultima settimana (mentre gli 

utenti inseriscono) o si chiudeva per tutta la durata per risolvere il 

problema (casistica che coinvolge il 3%) con conseguenza che gli utenti 

(tutti) impossibilitati ad inserire le spese, non potevano percepirle in 

busta paga. o avrebbero percepito (nel 3%) importi superiori, e poi 

decurtati il mese successivo.

o come abbiamo preferito ,lasciare l'operatività invariata, avvertendo 

gli utenti che in quei specifici casi non era possibile elaborarli ma si 

pregava di inserirli, andando a scrivere un log (tabelle di log) solo e 

soltanto quelle casistiche anomale e mettere in uno stato non lavorabile 

in contabilità solo quelle casistiche.

facendo così gli utenti hanno potuto percepire i rimborsi tranne per 

quelle casistiche.



la soluzione ha poi comportato 10 gg di lavoro, tra fare una regola ad 

hoc (analisi funzionale e compliant con le normative), implementarla, 

testarla e metterla in esercizio.



implementare lo switch (scrittura su log, e non lavorabilità solo per 

quelle casistiche), non ha comportato nessuna modifica lato server.

tutto questo è stato fatto con solo 2 ore di down, poichè tutta la BL si 

trova su oracle,



la scrittura del log ci è servita successivamente per bonificare i dati 

anomali e rimettere in lavorazione contabile.



se avessimo avuto la BL server side, saremmo dovuti intervernire su più 

fronti e in più punti, e forse avremmo avuto non 2 ore ma una giornata 

di down.



NB

il down è dovuto principalmente per non far continuare a sporcare la 

base dati.



scusate la prolissità

spero di aver chiarito il contesto.



Ciao




Ma vai a scoreggiare nella cenere!




 JSP 



questo è discutibile e come minimo dipende da cosa sta facendo il codice.

a guardar bene chi cerca le performance lo stored procedure sono il luogo 

meno adatto dove piazzare la logica business, per una serie infinita di 

ragioni. 





veramente bramante parlava di mettere tutta la logica di business dentro 

le stored procedure e non solo l'accesso al db.



Si e No

tutto sta a capire la BL che cosa fa, se deve far calcoli hai 

perfettamente ragione, un DB engine non è adatto, se deve scartabbellare 

dati, o fare aggregazione lo vedo molto più veloce che farlo fare ad un 

qualsiasi linguaggio.



poi tutto sta anche a come si programmano le SP.



capitò una volta che bisognava calcolare dei dati estratti dal db, quasi 

un paio di milioni di righe, la vecchia elaborazione prevedeva un 

accesso al db e fetchare le righe ed effettuare altri accessi su altre 

tabelle per prendere dei dati (e no, non si poteva andare di join 

semplice poiche si andava su tabelle differenti o viste a seconda del 

tipo di dato che si stava elaborando), e su ognuno eseguire dei calcoli.



Era scritta in COBOL con accesso oracle, il tutto su macchine UNIX 

(parliamo di 12/15 anni fa), era biblica come tempi di risposta, un 

report ci impiegava anche 2 ore. (era un batch schedulato settimanalmente).



riscritta in PL/SQL dimezzarono i tempi, poco più di 1 ora, ma stessa 

logica, cursore -> fetch -> altre chiamate sql e altri cursori -> calcoli.



la riscrissi con l'aiuto di un esperto oracle (fu il mio mentore), 

creammo una SP, che conteneva solo e soltanto una query da migliaia di 

righe, utilizzando le funzioni analitiche del db engine, con ENNE 

subquery, e case when, ci impiegammo l'intera settimana, era 

completamente illegibile (sia per lunghezza che per complessita e 

annidazione), ma il risultato fu strabiliante, meno di 20 minuti di 

elaborazione.



certo non oso pensare a doverci rimettere mano o chi lo ha fatto





Ciao


 di down.



non direi, o almeno non nei programmi che scrivo io. se non ho capito 

male la soluzione tampone prevedeva di dirottare altrove la scrittura di 

una tabella, ti dirò visto che in java è facile utilizzare un orm è molto 

probabile tu dovessi intervenire in un punto solo e con una modifica 

veloce almeno pari alla stored procedure.





un pò più complesso ma il concetto è quello



la soluzione tampone fu quella di intercettare la casistica errata, 

fargli continuare la normale operatività (diverse scritture e letture)

fargli scrivere la parte contabile in modo errato

mettere il record del dettaglio contabile in uno stato non lavorabile , 

ma mantenendo la transazione contabile attiva (per transazione intendo 

l'insieme delle note spese o richieste di indennità) poichè vengono 

considerate come un unico pagamento **



inviare nota (un record di segnalazione) alla contabilità per non far 

scartare il "pacchetto" ma stornare l'anomalia.

e scrivere il log con tutta una serie di informazioni.





** immaginalo come un unico pacchetto, richiesta indennità lavoro fuori 

sede, 2 notti in albergo, 2 viaggi treno, 4 forfait pasto con 

accompagno, ecc..



questo è stato fatto intervenendo in 2 punti, delle if per impostare dei 

flag nel momento in cui scattavano le condizioni che avrebbero scaturito 

l'anomalia, all'interno della SP.

e un altra if subito dopo la scrittura contabile per intercettare e 

controllare i flag e richiamare una SP creata ad hoc per fare le cose 

descritte sopra.



Ciao



E' un' altra cosa

Quello è sql chiamato da un programma.

Per facilitare i compiti e avere una portabilità maggiore si usa un 

preprocessore (al posto di #include si usa exec sql)

Anche per il COBOL è cosi,si chiama procob il preprocessore.






 qualsiasi linguaggio.



ma anche su questo c'è da ridire. lato application esistono soluzioni 

(memcached, strutture dati in memory, non-blocking i/o) che danno ampio 

margine di ottimizzazione a chi cerca performance anche spinte. mi 

riferisco soprattutto alle applicazioni web dove l'application server 

deve rispondere a diverse richieste simultanee. alla fine tolte le fasi 

batch non vedo altre applicazioni pratiche dove conviene realmente 

delegare l'elaborazione al db.




 il deploy più veloce).



Ah noto che l'idiota aveva risposto, mi permetto un consiglio Ale caccialo in KF.



Ciao

  Francesco


 delegare l'elaborazione al db.



Io posso portarti la mia esperienza: semplici scritture di documenti, immagina un flusso di scontrini, generano in realtà tutta una serie di operazione di BL (movimenti, flussi finanziari) che a loro volta ne posso generare altre (ordini automatici ad esempio). Avere la BL in SP toglie una montagna di lavoro al front end.



Inoltre questi flussi posso arrivare da interfacce fatte anche con tecnologie non web che rendono l'uso di WS molto complesso e quindi la BL in SP toglie il problema di duplicazione della logica.



Ciao

  Francesco


 Inoltre questi flussi posso arrivare da interfacce fatte anche con tecnologie non web che rendono l'uso di WS molto complesso e quindi la BL in SP toglie il problema di duplicazione della logica.



Ma quali tecnologie web??? I WS non sono consumati per forza da tecnologie web.



Mettiti d'accordo con te stesso prima di intervenire: si parlava di modifiche a caldo *e basta*, oppure di performance?



Vedi teledipendente o trevisano, qui qualcuno sta scrivendo che le SP vanno alla grande perche' ti consentono modifiche a caldo. Il che e'  una cazzata come ho dimostrato. Se quello e' l'obiettivo ci sono ennemila modi migliori di ottenere lo stesso risultato.


 spero di aver chiarito il contesto.



In realta' era gia' chiaro da prima a dire il vero.


 Ma quali tecnologie web??? I WS non sono consumati per forza da tecnologie web.



Indubbiamente no ma fare tutto via WS è molto complesso ad esempio da AS400 o da WinForm. Complesso e lento per tante ragioni.



Ciao

  Francesco 


 Indubbiamente no ma fare tutto via WS è molto complesso ad esempio da AS400



Questa affermazione e' da smentire nella maniera piu' categorica.



So che AS400 ha il supporto per il WS ma trovare qualcuno che lo sappia usare è purtroppo più difficile ti trovare chi di manda il file di scambio su csv.



Ciao

  Francesco




 il deploy più veloce).



Scrivi cagate, come al solito.






appunto. 









...e questo e' un altro paio di maniche.



Non è detto che se la BL fosse stata fatta in linguaggio convenzionale 

non avresti potuto intervenire nel DB.

Se ho capito bene il problema con qualche trigger su una o piu tabelle 

te la saresti cavata lo stesso.




 Secondo me la cosa che vi preoccupa in realta' e' quel "piu' fronti",



cioe' fare un deploy dell'applicativo Java vi richiede tempo e fatica.





non sai quanto è vera questa frase "richiede tempo e fatica."



Ciao







fammi capire, tu per risolvere un anomalia, intervieni sulla struttura 

della base dati???





Ciao



ci abbiamo provato, ma i tempi non erano accettabili, la richiesta fu 

quella di passare da una schedulazione settimanale notturna, ad una 

richiesta interattiva dell'utente.



quindi bisognava prima di tutto avere quel report il prima possibile, 

anche a discapito della manutenibiltà del codice stesso.



i dati elaborati non dovevano essere in tempo reale, si faceva 

riferimento a 7 giorni prima dal momento della richiesta.

quindi cercammo anche altre soluzioni come dei semilavorati, a delle 

viste materializzate, ma la parte che impiegava più tempo era sempre e 

comunque il ciclare milioni di record e a rottura codice.



Ciao


 non sai quanto è vera questa frase "richiede tempo e fatica."



Buonanotte.



Nessun cambio di struttura ma solo dei trigger che redirezionano le 

anomalie da qualche altra parte.

Naturalmente non conosco a fondo il problema,vado solo ad intuito.




 certo non oso pensare a doverci rimettere mano o chi lo ha fatto



E quindi che senso ha tutto ciò? Uno dei principi base della

programmazione software è garantire il riutilizzo e la modifica

dei sorgenti.








Sogni d'oro.






Per me è più facile sviluppare e mantenere bei pezzi di bl se non tutta 

direttamente dentro al db piuttosto che aumentare la complessità 

mettendo un object model sopra gestito a manina oppre via orm e 

manipolarlo con uno strato applicativo creato ad hoc, anche perché trovo 

l'approccio problematico in caso di evoluzione del db: una cross 

reference di chi usa cosa e come è più complessa.

Visto che stiamo parlando di oltp e intranet.










certo.

Però, come ha spiegato lui stesso, in quella situazione aveva dei

tempi stretti, e quindi ha optato per mettere in piedi una

soluzione che andasse, anche se dal punto di vista della

programmazione era un obbrobrio.



Purtroppo siamo sempre lì, presto e bene non stanno insieme.

E questa frase, che è un proverbio che mi ha insegnato mio

nonno quando ero bambino, io non la dico solo qui, ma anche

ai miei colleghi, ogni volta che mi fanno fretta o che dicono

che un lavoro è fatto male.





Per cui comprendo perfettamente la situazione in cui lui può

essersi trovato.



Per fare le cose bene bisogna avere a disposizione il tempo

di provare, sperimentare, rifare un pezzo daccapo perché

dopo che ci hai sbattuto la testa per due giorni hai capito

perché non funziona. 

E' così l'informatica, o almeno quello che io conosco

dell'informatica, che non sarà moltissimo, ma qualcosa è.



Se questo tempo, per qualsivoglia motivo, non c'è, non si può

fare altro che mettere su un accrocchio del cazzo, basta che

sta in piedi.





E il fatto che molti qui pensino che questa è una scusa non

cambia che le cose stiano così.









In ogni caso, che sia chiaro, tutto ciò non toglie che, come

ho detto prima, quando devo analizzare o modificare del

codice illeggibile lungo centina di righe mi incazzo come

un animale.

Ma non s può dare sempre la colpa al programmatore.






Eh, vaglielo a spiegare ai paladini che sviluppano nel modo migliore 

possibile (quello loro s'intende), ora ti verranno a dire che siccome 

siete una realtà del menga è bene che vi estinguiate per lasciar spazio 

ai meglio...

Oppure che li contattiate perché vengano li con la bacchetta magica a 

cambiarvi lo scenario...





Scrivo quello che hai scritto, se son cagate è un problema tuo.




 soluzione corrente funziona bene. Quindi, di che stai parlando tu?



Si certo, anche la pubblica amministrazione "funziona". Se prendi il treno prima o poi arrivi. Ma fammi il piacere.



Si sta parlando di best practice informatiche. Quello che a loro e a te sembra funzionare non e' oggetto di discussione, anche perche' non e' misurabile.



Non ho presentato alcuna alternativa intelligente che fa uso di JSP, se hai difficolta con l'italiano, quello si, e' un problema tuo (e piuttosto serio).


 mettendo un object model sopra gestito a manina oppre via orm 



Quindi riassumendo, il web e' troppo difficile, gli orm sono ingestibili, i layer applicativi non servono (e faresti applicativi interi praticamente solo con le SP). 



Ma non eri un espertone di backend?




E tu non eri quello che non scriveva cagate?






Ah, ti piace fuffare, ok.




 Ok, me lo segno, su carta igienica però.



E' come giocare a scacchi con chi non sa le regole: una noia e una perdita di tempo.


 specialemente le parti più complesse e critiche (cruciali).



Aaah. Immagino Facebook sia fatto a botte di SP allora. No aspetta, solo nelle sue parti piu' complesse e critiche (nonche' cruciali).


 sta in piedi.

CUT



Tu ti faresti curare da un dentista che, a causa

di "tempi stretti", ti mette due pezze veloci in bocca e via?











forse mi sono spiegato male, i tempi non accettabili, non erano di 

sviluppo, ma di risposta del report.



abbiamo provato per settimane diverse soluzioni, ma la più veloce in 

termini di risposta fu la mega query, (che per inciso non piaceva a 

nessuno, ma da cui ho imparato come funziona un dbms e le sue 

potenzialità in termini di manipolazioni dati), e non fu neanche 

"l'ultima" soluzione messa in campo.

quando presentammo le diverse soluzioni (mega query, semilavorati e 

viste materializzate con SP di estrazione), fu scelta quella che 

produceva il report nel minor tempo possibile.



un conto è che l'utente inserisce i parametri di estrazione clicca 

"elabora", va a prendersi un caffè, fumarsi una sigaretta tornare e 

ricevere l'email con allegato il report.



un altro è fargli aspettare 2 ore, per lo stesso report.





Ciao


 direttamente dentro al db piuttosto che aumentare la complessità



"più facile" è soggettivo e non lo discuto, d'altra parte se le altre 

soluzioni non le conosci per te è più facile per forza.

al di là di quella che ritengo la strada più facile da percorrere io mi 

sforzo di valutare la soluzione che è oggettivamente migliore.




 toglie una montagna di lavoro al front end.



toglie il lavoro ad un application server che di certo non si 

scandalizzarebbe di fronte ad un business process come quello che hai 

descritto. anzi, potrebbe pure mettere a disposizione strumenti che ti 

consentirebbero di implementarlo in modo quasi dichiarativo. 

si sta parlando di strumenti che nascono per fare queste cose, non si è 

mai sentito che un application server non sia adatto ad ospitare la 

business logic... 



scusa ma dove sta scritto??



non confondere i principi della OOP con i principi(modelli) di sviluppo 

software.



da wikipedia

I modelli di sviluppo software simulano la realtà per vedere cosa 

accadrebbe, e al fine di ridurre gli errori e di "ottimizzare le 

prestazioni e i risultati."



poi se parliamo dei principi agili

http://agilemanifesto.org/iso/it/principles.html


(e qui magari peccammo :

La continua attenzione all'eccellenza tecnica

e alla buona progettazione esaltano l'agilità. )



considerando che erano i primi anni 2000 la metodologia che andava per 

la maggiore erano la waterfall e la spiral (ancora oggi largamente 

utilizzati nelle grandi aziende)



Ciao






vero,



Infatti quando entrai nel team (che si stava creando),fu uno dei punti 

che contestai, perchè utilizzare SP per la BL, dato che esistono 

soluzioni migliori e più performanti.



mi fu data in risposta una serie di ragioni che all'epoca non capivo e 

non mi piacevano.



oggi dopo tre anni, ne capisco le ragioni e apprezzo la scelta (sempre 

in riferimento al contesto lavorativo).



questo non vuol dire che opterei per la stessa soluzione in contesti 

diversi.

anzi, se il contesto lo permette, oserei proporre soluzioni il più 

possibili aggiornate e che facciano uso di Best Practices.



Ciao






un WS è una tecnologia WEB, che non sia consumato solo da browser o app, 

non vuol dire nulla, ma sempre su protocollo HTTP viaggia.





Ciao


 scandalizzarebbe 



Il problema, a mio avviso, nasce quando di application server ne hai più d'uno.

Avere le parti cruciali della BL, quelle che garantiscono l'integrità stessa dei dati, su SP di salva da errori nati dalla duplicazione della logica, magari in linguaggio ed ambienti diversi.



Ciao

 Francesco



Un client che fa chiamate http *NON* e' una tecnologia web. 



Non per quel motivo, almeno.








ciccio, che domande...

certo che no (anche se, considerando quello che costano i dentisti,

se mi fa risparmiare e nello stesso tempo mi fa passare il mal di denti

un pensierino ce lo potrei fare...).



Comunque, battute a parte, non puoi paragonare un contesto come

quello di cui stiamo discutendo al lavoro del dentista, per ovvie

ragioni, direi.



Per prima cosa, il dentista cura la salute dei denti, quindi di una

parte del corpo, non scrive programmi al pc. Quindi, mi pare ci sia

una bella differenza tra il danno potenziale di un dente mal curato

e il danno potenziale di un programma con un bug.



Secondariamente, di solito non è che al dentista fanno pressioni

perché finisca alla svelta. Se ho mal di denti e c'è da fare

un intervento complicato, io voglio che subito mi faccia qualcosa

che mi tolga il dolore, poi il resto si fa con calma, in più

sedute (come ho fatto spesso, del resto): una persona intelligente

fa così.



Invece, come tu saprai bene, il lavoro del programmatore si svolge

in contesti del tutto differenti.





Su, ciccio, non puoi venirmi a fare paragoni del genere, non hanno

alcun senso.



In teoria avresti ragione, ma nella pratica capisci meglio di me che

un discorso così non sta in piedi.




 





ok, in effetti avevo capito che non erano accettabili i tempi di

sviluppo.

Comunque la questione di fondo rimane sempre la stessa, cioè

il fatto di adottare una soluzione che fa quello che si vuole, ma

va a discapito della leggibilità e della manutenibilità.





Io a questo punto, una volta stabilito che ci vuole per forza la

mega query che scritta con un blocco sql risulta illeggibile,

mi domanderei se non conveniva piuttosto fare sì la mega query,

ma comporla lato server costruendo diverse classi e metodi, in

modo da avere diversi blocchi di codice ognuno con la sua funzione

specifica.

Non so che linguaggio usavate, ma col java una cosa come questa

è fattibile senza eccessive difficoltà, in genere.



Così si sarebbe ottenuto un risultato simile in termini di performance,

e nello stesso il codice sarebbe stato più leggibile e più

facilmente manutenibile.





Ecco, magari piuttosto che fare una unica sp, forse si poteva prendere

in considerazione una possibilità come questa, o no?




 logica, magari in linguaggio ed ambienti diversi.



sulla centralità della business logic siamo d'accordo, il problema è dove 

centralizzarla. in java ee ormai sono svariati lustri che esistono 

protocolli per invocare in modo anche molto trasparente (leggi: senza 

cambiare nulla rispetto ad una chiamata locale) procedure remote, penso 

agli ejb o al jms. recentemente poi hanno avuto larga diffusione i 

protocolli basati su http (rest, rpc) che sono agnostici rispetto ai 

linguaggi chiamanti. tutti sforzi proprio per non avere la bl duplicata 

sui client bensì centralizzata, ma con tutti i vantaggi quali la 

scalabilità, load balancing, sicurezza configurabile con granularità, 

transazioni distribuite, eccetera, eccetera.


 specialemente le parti più complesse e critiche (cruciali).



a parte le chiacchiere secondo te in un application server cosa ci 

dovrebbe andare, se non la logica di business?

per capire.


 per capire.



Credo che il minchione non sappia neanche cosa sia un a/s.


 eh?



In sostanza non ha mai usato un orm e non sa che cosa e'. 



E straparla come al solito.


 In sostanza non ha mai usato un orm e non sa che cosa e'.



ma quella non è neanche una frase di senso compiuto.

"ricavare in fretta l'uso dei campi e delle tabelle del tuo db da parte 

degli applicativi". che vuol dire?






Il senso di avere una richiesta che per applicare le regole di bl legate 

a quella richiesta possa generare connessioni parallele sul db quale 

sarebbe?

Nei casi in cui è richiesto che un batch lato db possa ritornare al 

chiamante prima di aver finito il proprio compito è già gestibile lato 

db tramite, per esempio, il service broker di ms sql server.

Ma sono scenari particolari di oltp, non costituiscono di certo la 

maggior parte delle transazioni che arrivano ad un db durante l'uso di 

quel tipo di applicazioni.




 [...]

Se hai finito con la cenere, puoi tranquillamente andare a cagare sopra 

le ortiche.





Hai presente cos'è una cross reference? Chi usa che cosa?

Indovinato.




 So che AS400 ha il supporto per il WS ma trovare qualcuno che lo sappia usare è purtroppo più difficile



Questo e` un problema diverso. Se affermi che qualcosa e` troppo 

complesso perche` sei incompetente, il problema e` tuo...



-- 

4ndre4

"The use of COBOL cripples the mind; its teaching should, therefore, be 

regarded as a criminal offense." (E. Dijkstra)

"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 

http://goo.gl/1nrkkX




LOL :) Dai, spiegaci cosa volevi dire, genio!



 Hai presente cos'è una cross reference? Chi usa che cosa?



Eh?! Cosa c'entra con un ORM? LOL :) Ti incarti sempre di piu`...



 non vuol dire nulla, ma sempre su protocollo HTTP viaggia.



E` stata detta una cosa diversa:

"Inoltre questi flussi posso arrivare da interfacce fatte anche con 

tecnologie non web che rendono l'uso di WS molto complesso"



Il consumer di un web service non deve essere necessariamente scritto 

con una "tecnologia web". Qualunque sistema, ormai, ha accesso ai WS con 

enorme facilita`, persino RPG/COBOL su System i 

(
http://www.ibm.com/developerworks/systems/library/es-webservicesrpg/
) 

per cui l'obiezione proprio non regge. Usare HTTP significa usare 

semplicemente un protocollo come un altro. Almeno e` un protocollo 

aperto. Connetterti direttamente ad un DB significa - nella stragrande 

maggioranza dei casi - usare un protocollo proprietario.



 Ah noto che l'idiota aveva risposto, mi permetto un consiglio Ale caccialo in KF.



Idiota e` quel che sei, e lo dimostri bene da quel che scrivi. Mettere 

gente nel kill file e poi cagarsela comunque e` proprio da beota quale 

sei :D



On 16/02/2016 20:51, bramante wrote:



[...]

La situazione che descrivi non rende assolutamente chiaro perche` avere 

una BL scritta su Oracle, organizzata per package/sp, debba essere piu` 

facile da manutenere di una logica scritta come codice Java in business 

objects tenuti in piedi da un application server. Server e` uno, server 

e` l'altro. Il fatto che modificare codice Java avrebbe comportato una 

fatica maggiore non e` un limite della tecnologia; e` un limite del 

VOSTRO processo aziendale. Oltretutto, una BL scritta in Java comporta 

la possibilita` di scrivere unit test / integration test / acceptance 

test, ecc.. Voi, ora, come testate che il codice PL/SQL non regredisca?



 Ah, ti piace fuffare, ok.



Come al solito, non hai capito un cazzo di quel che si sta dicendo. Si 

sono messi a confronto due modi di fare le cose (logica su a/s e logica 

su sp) ed e` stato detto che avere la logica su sp si e` rivelato molto 

piu` facile che farlo in altro modo. Il punto e` che modificare la 

logica su sp o farlo su a/s non comporta assolutamente nessun tempo 

minore. Il tempo, semmai`, e` legato al PROCESSO di rilascio, e il 

processo di rilascio e` totalmente indipendente dalla tecnologia usata. 

Il punto e` che >>> NELLA *SUA* AZIENDA <<< rilasciare modifiche al 

codice Java richiede molto piu` tempo che "patchare" il codice PL/SQL - 

il che non e` un vantaggio OBIETTIVO di PL/SQL vs. Java, ma cio` che 

semplicemente accade >>> NELLA *SUA* AZIENDA <<<.



 reference di chi usa cosa e come è più complessa.



Stai dicendo, come al solito, un mare di stronzate. La bl tenuta dentro 

un a/s non aumenta affatto la complessita` del sistema. Cristo, quanta 

incompetenza...





http://cft.foodforthebrain.org/





 Indovina?



Rispondi, idiota: cosa c'entra con un ORM?



 sarebbe?



scrivi in maniera incomprensibile, ad ogni modo cercherò di risponderti.



https://en.wikipedia.org/wiki/Asynchronous_I/O




in soldoni mentre la richiesta al database è in attesa della risposta, il 

programma prosegue facendo altro. nella fattispecie soddisfa altre 

richieste.


 Indovinato.



scusa ma sei uno di quei bot che generano frasi a caso?


 scusa ma sei uno di quei bot che generano frasi a caso?



Forse non e' una strategia cosi' peregrina: gettare fumo sul thread per uscirne di soppiatto.






ESATTO



a parte che non è l'azienda, ma per me il cliente, è una PA, che come ho 

scritto ha le sue regole "burocratiche" per il deploy.



quando in un altro post indicavo

non sai quanto è vera questa frase "richiede tempo e fatica."



non perchè richiedesse tempo o fatica il deploy o lo sviluppo, ma lo 

avere a che fare con tutto il resto.



Ciao






se hai seguito l'intero thread, e come giustamente hai fatto notare 

nell'altro post, non ho mai detto che avere la BL su dbms è LA soluzione 

migliore, anzi all'inizio l'ho fortemente contestata.



ma che nel contesto lavorativo si è rilevata la scelta più idonea.



PS

la gestione dei deploy è demandata ad altro gruppo di lavoro che è del 

cliente, con un audit su cio che viene rilasciato.

questo significa che noi creiamo il ticket di rilascio con le specifiche 

del perchè si sta rilasciando (bug, features, ecc) le specifiche 

dettagliate su cosa si rilascia (e fino a qui mi sembra cosa buona e 

giusta) e il link di dove andare a prendere l'EAR  (non abbiamo un tool 

di continuos delivery)

poi passano 2 o 3 livelli di visione/approvazione prima di arrivare 

finalmente in prod.



avere per consuetudine (leggila quasi burocratica), la schedulazione 

settimanale dei rilasci, e sempre per consuetudine l'emergenza di un 

rilascio viene considerata un "favore" che ti viene fatto, poter in 

qualche modo non chiedere "favori", e essere sempre disponibili nei 

confronti dell'utente che richiede "al volo" o il prima possibile una 

aggiunta/modifica di BL, ti mette su un altro livello di rapporto con il 

cliente.



chiamiamola politica :)



poi giustamente quello che scrivi che una BL su AS hai maggiore 

controllo è verissimo.



come testiamo che non regredisca??

bella domanda, nei casi di SP complesse, o che richiama a cascata n SP, 

abbiamo per necessità creato degli "unit test" (prendi per assodato che 

non si tratta di veri unit test, con assert e fail).

un altra SP, che richiama quella da testare e ne genera l'output, da cui 

andiamo a controllare i risultati.



ho provato inizialmente ad usare utplsql

http://utplsql.sourceforge.net/




ma ci ho rinunciato.



nella maggior parte dei casi si va di debug.



Ciao



ti ricordo che stiamo parlando di un report che era scritto inizialmente 

in COBOL e che la richiesta di modifica è avvenuta i primi anni 2000 

(2000 o 2001) , e che dove ero si stava appena facendo il nuovo sistema 

con tecnologie web (java 1.2) e che concetti come ORM ancora non 

esistevano o erano talmente embrionali da non essere presi in 

considerazione.



poi la richiesta era comunque di un applicativo scritto in COBOL, che 

doveva permettere di inserire i parametri e premere il tasto elabora, e 

produrre il report.



Ciao


 considerazione.



le richieste di reportistica spesso confinano con l'analisi del dato e la 

business intelligence, ci si inerpica in un terreno abbastanza complicato.

come ben sanno gli esperti di strumenti specifici spesso bisogna 

preparare il dato da presentare, allora ben vengano gli strumenti (stored 

procedure, viste, viste materializzate) che offre il database.




 finalmente in prod.



questo però capisci fa a cazzotti col fatto che poi gli sviluppatori 

hanno i privilegi per intervenire a cuore aperto sulle stored procedure. 

è il classico caso di responsabilità distribuite in modo ottuso; il 

database non è sotto la responsabilità di quel gruppo di lavoro quindi 

chissenefrega se ci viene buttata merda :-)



Indovina?






Ma quindi? Sono chiamate asincrone, ok, quindi che problema c'è nel 

farle quando si va sul db per invocare una sp e nel mentre il processo 

chiamante è libero di fare altro e cioè servire altre request?

Nessuno.






Emerito testa di cazzo, l'ORM non nasconde la struttura del db?

Bravo. Se voglio avere una cross reference sull'uso della struttura del 

db (hai presente vero? Quello con le tabele con oguna i suoi bei campi) 

da parte di chi usa le classi che l'orm mette a disposizione, quanto è 

facile e veloce farlo?

Lato db con due query alle viste che tengono i metadati della struttura 

ci sto un attimo e sono sicuro di quel che ottengo, ammesso ovviamente 

che non ci siano client che vanno per conto loro sopra al db accedendo 

direttamente alle tabelle.

Hai capito, serve un disegno, magari a colori?

Ah, dimenticavo.

COGLIONE.





Mhhhh, mi sa che voi due di esperienza su sviluppo lato db ne avete 

pochina pochina, a parte avere tabelle e i comandi standard sql altro 

non ci mettete:



http://tinyurl.com/zzga3h3





 nella maggior parte dei casi si va di debug.



Per la centesima volta: il debug *NON E`* uno strumento di regression testing.


 ci sto un attimo e sono sicuro di quel che ottengo



E chi ti vieta di farlo comunque, anche usando un ORM, COGLIONE?



LOL :) Ma perche` continui a parlare senza sapere quel che dici?


 pochina pochina



HA HA HA HA HA HA HA HA 


 Forse non e' una strategia cosi' peregrina: gettare fumo sul thread per uscirne di soppiatto.



D'altronde e` un suo classico: il trevigiano/televisivo la butta in caciara, per poi fuggire in una nuvola di polvere come Wile Coyote (e con risultati ugualmente disastrosi).




 chiamante è libero di fare altro e cioè servire altre request? Nessuno.



ma infatti non c'è alcun problema di fattibilità. il problema è di 

*performance*: se tutta la business logic è demandata alle stored 

procedure significa che *tutte* le request passano il 100% del tempo in 

idle, è come dire mentre aspetto mi metto a fare altro ma questo "altro" 

è ancora stare fermo ad aspettare. 




 
http://tinyurl.com/zzga3h3




questo ci sta, ma a giudicare proprio dai grafici che tu stesso hai 

postato pare che sia una pratica in progressivo abbandono da una 

quindicina di anni.

mi chiedevo se avevi notato la cosa, prima di buttare questo grafico 

nella discussione. no perché non mi sembra deponga molto a favore di ciò 

che tanto focosamente sostieni.


 nella discussione.



Che poi quel grafico chi l'ha creato? Suo cugino?




 Per la centesima volta: il debug *NON E`* uno strumento di regression testing.



lo so, ma è un modo per verificare che non ci siano errori, e che 

l'output generato sia congruo con il risultato atteso.



Spero che da qui hai prossimi mesi qualcosa si muova (è in atto un 

cambiamento radicale) e che vada in altra direzione, non solo tecnica.



Ciao


lo so, ma è un modo per verificare che non ci siano errori



Regression testing e "nuovi errori" sono due concetti diversi.



Come vedi, tu trovi dei benefici nell'avere la BL su db, ma scavando, si scopre che esistono enormi fragilita` nel vostro ambiente di lavoro. Una di queste e` che non riuscite a garantire che la logica di business non regredisca.


 si`, molto probabilmente dovuto alla vostra incompetenza. Perche` escluderla?



Perchè non è stata una scelta voluta, ma imposta o comunque fortemente 

caldeggiata da persone influenti.



Se quando porti una novità o una miglioria (vedi utplsql, che avevo 

provato ad utilizzare),  ti viene detto che non è uno strumento 

ufficiale, che non si possono mettere sulle macchine di collaudo e 

sviluppo, che non appartiene al parco software della PA, e che non c'è 

nessun licenziatario in caso di problemi, vien da se che NON puoi 

utilizzare quello strumento.



stessa cosa per le segnalazini che ci arrivano (per email), un sistema 

di Trouble Ticketing interno per queste segnalazioni non esiste (ma 

esiste per altro) e non è contemplato, ho proposto OsTicket, ma mi è 

stato risposto, come sopra.



quindi per favore e per correttezza intellettuale, non dare delle 

incompetenze senza sapere fatti o situazioni.



Ciao






 caldeggiata da persone influenti.





Si ma e' una soluzione che tu apprezzi. 



Vedi, nel cercare di tenere il piede in due scarpe alla fine ti sei contraddetto.


 incompetenze senza sapere fatti o situazioni.



Quindi posso dire che lavori in un ambiente di merda comandato da INCOMPETENTI influenti che "caldeggiano" soluzioni sbagliate?


 utilizzare quello strumento.



Ma siamo sicuri che hai capito cosa e' un unit testing framework? O che l'hai fatto capire al "capo"?



Quello che scrivi e' privo di senso. E' un framework per lo sviluppo, non ha bisogno di nessun collaudo e licenziatario (soprattutto tentendo conto che non sta soppiantando nessun altro software).



Oppure prima di applicare un design pattern andate a vedere dove sta il licenziatario? O lo eseguite su un server di collaudo! 



"Bramante, ha funzionato bene il builder pattern sul nuovo e certificato mega server di collaudo?" 



??????


 Ma siamo sicuri che hai capito cosa e' un unit testing framework? O che l'hai fatto capire al "capo"?



Ma poi, come si fa a lavorare in un ambiente in cui le scelte tecniche vengono imposte da qualcuno che non capisce un cazzo di tecnico (e si vede bene), che non capisce che ormai si sviluppa dotandosi degli strumenti open source piu` vari, che pretendere che il software che uso appartenga al "parco software della PA" e` una gran cagata, e che non c'e` bisogno di alcun licenziatario in quanto, appunto, software free? Oltreutto qualcuno che ti vieta di mettere in piedi macchine di collaudo e sviluppo? Ma scherziamo? Bah... che posto di merda...







non mi sembra che il fatto che sia imposta, non possa essere apprezzata.



non sarà lo stato dell'arte, non sarà la migliore, ma se garantisce un 

livello di servizio superiore e che soddisfa il cliente non vedo che 

male ci sia.



non ragionate solo in base alla parte tecnica, rimarrete sempre e 

soltanto dei tecnici.



ragionate a più ampio livello.



l'informatica serve per soddisfare un bisogno, e migliorare la vita di 

chi ne usufruisce.



il gruppo di lavoro in cui faccio parte gestisce un portale con N 

funzionalità per i dipendenti di una PA, ora alcune scelte 

architetturali ci sono per così dire veicolate, altre sono di nostra 

libera iniziativa, noi bisogna garantire una serie di servizi e 

operatività, dare supporto e risolvere le problematiche che man mano si 

incontrano e cerchiamo di fare il nostro meglio.



la discussione iniziale verteva sulle esperienze di avere la BL su dbms, 

io ho portato la mia, ne ho descritto i pregi per il modo operandi del 

contesto lavorativo.



poi che ci siano modi diversi va benissimo, e ne sono un fautore, ho 

diversi progetti personali, che mi danno soddisfazione, in un caso la BL 

è in un WS, in altro nel classico M dell'architettura MVC, altro 

progetto a cui ho partecipato si trovava come EjB.



Ciao



sai che cosa'è utPLSQL?

è si un framework di unit test, ma essendo scritto in plsql, si deve 

"installare" sopra un dbms come package oracle, creare un utente, una 

serie di tabelle, view, session ecc..



ora per installare un PKG di "terze parti" all'interno delle macchine d 

sviluppo e collaudo bisogna che qualcuno si assuma la responsabilità 

(per qualcuno intendo un tizio cliente), il quale ha o mette dei paletti.





Ciao



di software open source ne siamo pieni, anzi l'istituto sta man mano 

migrando a software OS, come da normativa, sta facendo passi da gigante 

su opendata e servizi interconessi e formati aperti.



ma tu vuoi sapere come vengono spesi i soldi di una PA, per 

licenziatario forse mi sono espresso male, intendo un vendor, un entità 

commerciale che dia supporto in caso di proplemi.



il fatto che sia open source non vuol dire gratis, e non vuol dire che 

se ho problemi non so a chi rivolgermi.



per parco software della PA, si indica la dotazione del software che è 

in essere all'interno della PA, sia esso proprietario, open source o 

fatto in casa.

anche perchè tu da cittadino vuoi sapere come dove vanno finire i 

milioni di euro di ogni gara e di conseguenza le tasse che paghi.





fai una cosa vai su 
WWW.CONSIP.IT
 e cerca gare, leggitene alcune e poi 

forse riusciamo a capirci in che mondo lavoro.





Ciao



hai riassunto come funziona una PA.



Ciao


 ragionate a più ampio livello.



I manager, quelli bravi, non ragionano cosi'. Risolvono i problemi, se ci sono problemi, soprattutto se sono di carattetre burocratico e di metodo. Servono esattamente a quello.



Di manager che si barcamenano non ce n'è alcun bisogno, e chi lavora in un ambiente del genere farebbe bene ad andarsene prima che sia troppo tardi.


On Friday, 19 February 2016 16:21:18 UTC, bramante  wrote:



[...]

Se vuoi davvero pontificare su cosa gli altri debbano o non debbano ragionare o sull'informatica che "deve migliorare la vita delle persone", devi almeno sforzarti di fornire degli esempi validi e non l'hai fatto. A me fa ridere il fatto che tu creda che chi metta in luce evidenti falle nel modo in cui lavori sia solo un "tecnico" che si ostina ad essere "tecnico" e non vedere oltre. Fino a che ho lavorato in Italia, sono stato spesso chiamato a risolvere casini creati dagli altri, per cui, a ragione, posso dirti cosa c'e` di sbagliato nel vostro modo di lavorare, anche solo basandomi sui pochi indizi ricevuti. Quel che hai scritto "puzza". Garantire "un livello di sevizio superiore" che cosa significa? Niente. Come gia` detto, la vostra non e` una scelta strategica, e` solo un ripiego di comodo per i limiti tecnici del vostro ambiente. A voi viene semplicemente piu` facile, per via del modo in cui VOI avete impostato il VOSTRO ambiente, fare un delivery di modifiche su BL su DB, piuttosto che codice Java che gira in un app server. Non c'e` un vantaggio oggettivo, e` solo il VOSTRO ambiente a "pendere" da una parte piuttosto che dall'altra. I "pregi" che tu descrivi sono solo pregi oggettivi, sono solo vantaggi che si hanno nel tuo specifico ambiente di lavoro, e per evidenti mancanze. Oltretutto, il fatto che esistano personaggi di dubbissima capacita` tecnica i quali dettano le regole e vietano, ad esempio, di usare un tool come utplql mi fa pensare che da un ambiente del genere, una persona che tiene veramente alla propria competenza e crescita tecnica, debba scappare a gambe levate, appena puo`.




:-D Spiegami come si fa, che son curioso, fammi vedere l'agevolezza 

nell'ottenere un elenco di classi + metodi che accessi crud fanno sulle 

tabelle del db.

Ah lesbico!




 che tanto focosamente sostieni.

Focosamente? Ma dai. Rispondo a tono a certi pistola.

Negli altri casi non mi pare proprio di esprimermi focosamente.









Non ci stiamo capendo. Guarda che una sp mica è un singleton e può 

girare solo in un'unica istanza, quindi non capisco il senso della tua 

considerazione, così come chiamate asincrone al db ci possono essere per 

soddisfare contemporanemente più request accedendo direttamente alla 

tabelle per delle crud semplici, allo stesso modo quelle chiamate ci 

possono essere perché si accede a sp che internamente hanno della bl.





http://thehelsinkideclaration.blogspot.it/









mi sembra di aver detto che quando sono entrato nel team non ne capivo i 

motivi e non mi piaceva come soluzione, e che dopo 3 anni ne apprezzo i 

vantaggi in riferimento al contesto lavorativo, non mi sembra di 

cambiare versione.



ora che sia una scelta imposta o meno non fa differenza.



quando dico che ne apprezzo i benefici che mi contestate, leggitimo ma 

non avete portato uno e dico uno straccio di prova sul perchè una 

soluzione diversa sia migliore in assoluto.

non avete portato esperienze, dirette o indirette, non avete messo a 

confronto nella realta i due approcci, avete solo dato per scontato che 

avere una BL su AS sia migliore.



io ho solo portato la mia esperienza, poi di cose che non mi piacciono, 

uff ne sono pieno.



soprattutto dell'incapacità di vedere oltre il proprio orticello di chi 

deve decidere sul futuro dell'istituto dove attualmente lavoro.



di scelte che reputo anacronistiche, come l'obbligo di utilizzo di XML 

al posto dei JSON, o come una architettura SOAP al posto di REST, la 

limitazione di utilizzare javscript (ex legge stanca) e tante altre.



vero pero che ci deve essere uno standard comune per tutte le PA sia 

centrali che locali, e che il ministero preposto ha dovuto fare delle 

scelte.



Ciao


On Friday, 19 February 2016 18:02:35 UTC, AleTV  wrote:



[...]

LOL :) Snip su tutto il mare di cazzate che scrivi. Ma stai zitto, idiota. Dimostri di non capire un cazzo di niente. Non val neanche la pena risponderti. Ti dimostro invece l'agevolezza dell'ignorare quel che scrivi. Che grandissimo incompetente e beota.


 Focosamente? Ma dai. Rispondo a tono a certi pistola.



Ma stai zitto, COGLIONE, ma non vedi che fai solo figure di merda? :D Posta il grafico fatto dal cugino e pensa di dire cose importanti. Che imbecille, porca troia...


On Friday, 19 February 2016 18:10:11 UTC, AleTV  wrote:

[...]

Postare link a cazzo non ti aiuta, IDIOTA.




quando dico che ne apprezzo i benefici che mi contestate, 



Quel che non stai capendo e` che non ti viene contestato che tu non debba riconoscere dei vantaggi nell'ambito specifico in cui lavori. Quel che non stai capende e` che non c'e` ALCUN vantaggio OGGETTIVO nel creare una BL su database piuttosto che implementarla in Java, su a/s. Quando si inizia una discussione su quale sia il modo migliore di implementare un B/L e tu vieni fuori con un "all'inizio pensavo fosse una cagata tenere la B/L su database, ma poi ne ho trovato i benefici" stai dando un giudizio universale, stai parlando di benefici oggettivi. Hai solo successivamente ripiegato sul fatto che, in realta`, tali benefici esistono solo nel TUO ambiente di lavoro, e perche` sul fronte Java siete VOI che lavorate col culo. Almeno una prova del perche` avere una business logic implementata in Java, su a/s, sia una soluzione migliore ti e` stato fatto, ma non lo hai capito: il codice Java e` testabile, il bug che tu hai segnalato si puo` catturare come acceptance criteria da soddisfare e scrivere test adeguati perche` il sistema non regredisca. Si possono scrivere unit test, integration test, acceptance test, e quant'altro. Si possono usare i vantaggi della programmazione OO rispetto a quella PL/SQL procedurale. Si puo` versionare il codice (auguri a farlo con PL/SQL). Se serve integrare il sistema con servizi esterni, devi COMUNQUE implementarlo in Java, perche` non penserai mica di farlo da PL/SQL? Mantenere due code base, una in Java e una in PL/SQL puo` essere dispendioso da molti punti di vista. Continuo?


 





se è così, a giudicare dal mondo che vedo con i miei occhi, 

ho paura che l'informatica abbia mancato il suo scopo.

Siamo in un'epoca n cui è tutto informatizzato, ormai quasi tutti

hanno un PC, eppure guarda quanta gente c'è che sta male

(non solo fisicamente, anche psicologicamente, che è anche peggio).


 e alla buona progettazione esaltano l'agilità.



Perche`, voi siete un ambiente agile?



-- 

4ndre4

"The use of COBOL cripples the mind; its teaching should, therefore, be 

regarded as a criminal offense." (E. Dijkstra)

"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 

http://goo.gl/1nrkkX



 in contesti del tutto differenti.



Il tuo, forse, di certo non il mio.



 





dimmi una cosa: io in quell'epoca andavo ancora al liceo, e di

informatica non sapevo praticamente nulla, e ho iniziato a

fare questo mestiere nel 2008: ma a quei tempi, a prescindere

dal contesto che è oggetto della discussione, non sarebbe stato

possibile in java implementare una soluzione come ho detto io,

cioè creare classi e metodi che compongono la mega query, assegnando

a ciascuna/ciascuni di questi il compito di comporre una 

determinata parte della query?

Lo chiedo per curiosità.



A fagiuolo, uno per ciascuna delle ultime 3 "repliche":

https://www.youtube.com/watch?v=zwQi8p0ePLo




Ah lesbico!


On 19/02/2016 19:33, 4ndre4 wrote:


Ah, ho visto che costi 48 dollari l'ora, vuoi che ti faccio contattare 

così arrotondi?


è una mancanza di rispetto nei confronti degli altri colleghi.



A parte le questioni di rispetto (alla base di ogni nuova funzionalita` che si implementa ci dovrebbe essere la domanda: quanto facile sara` cambiarla in futuro? - e questo vale per i colleghi, ma anche per te stesso), il problema e` che significa mettersi un cappio attorno al collo, che si stringe sempre piu`, col passare del tempo. E` una sorta di technical debt che non si riesce a recuperare praticamente mai piu`, una mina vagante: bisogna solo aspettare che scoppi. Scrivere codice di merda non e` *MAI* una soluzione - neanche quando i tempi sono strettissimi; bisogna smettere di pensare che programmare significa cagare in un editor a comando del manager di turno, e cominciare a pensare al proprio lavoro in termini ingegneristici. Purtroppo, fino a che non si lavora in maniera veramente Agile, e` duro da capire.



Non mi stupisco

Nelle PA e anche in grosse aziende private funziona cosi

E per installare del sw su un db di sviluppo poi.




 db... 



sì l'ho notato, ma volevo sorvolare. l'idea che le stored procedure e il 

pl/sql stiano avendo un impennata verticale la trovo risibile, con 

rispetto parlando.

vedi se trovi un'infografica più efficace, o in alternativa cita 

l'articolo da cui l'hai tratto.


 E per installare del sw su un db di sviluppo poi.



Col cazzo. Io lavoro in una grossa azienda privata e la scelta tecnica 

di quale tool utilizzare, nel lavoro di tutti i giorni, la faccio *IO*, 

non un manager che non capisce un cazzo di tecnico, e tantomento un 

"tizio cliente". Il manager viene solo interpellato se ci sono licenze 

da comprare, ed il suo coinvolgimento rimane in ambito commerciale. Un 

ambiente in cui bisogna chiedere permesso a qualcuno, per poter 

installare roba su macchine di *SVILUPPO* e *TEST* e` un ambiente di 

merda dal quale scappare a gambe levate. Cosa c'entra, poi, il cliente 

con la metodologia di unit testing da adottare???



Scusami ma non ho resistito..

http://xkcd.com/844/








Da qualche gg ti ho tolto dalla black list,almeno per ridarti una 

opportunità che ritengo che meriti visti che imbecille non lo sei ma 

arrogante si (ma chissà cosa sia peggio).

Vedo che comunque sei rimasto lo stesso.

Per te discutere in modo civile è come chiedere ad un islamico di 

convertirsi al cristianesimo.

Ed ora veniamo alla tua tesi.

La tua azienda non è tutte le aziende del mondo e io ho scritto anche in 

grosse azienda private il che significa non in tutte le grosse aziende 

private.

Buon per te se da te la burocrazia non ha raggiunto tali limiti.






 private.



"Nelle PA e anche in grosse aziende private funziona cosi". Questo e` 

quello che hai scritto. No, in "grosse aziende private" che lavorano 

come si deve lavorare, non "succede cosi`". Nelle grosse aziende private 

che lavorano *COL CULO* succede cosi`. Hai dimenticato "col culo".



 possono essere perché si accede a sp che internamente hanno della bl.



è chiaro che non ci stiamo capendo. io sto parlando di i/o asincrono e te 

mi rispondi con le chiamate asincrone che possono essere fatte su una 

stored procedure, come le dbms_job di oracle, che non c'entrano nulla. 



ad ogni modo è un impasse che può facilmente essere superato, questa è 

solo una delle decine di confutazioni a chi sostiene che è meglio 

implementare la logica applicativa sul database e neanche la più 

importante.  








Va bene,ho fatto a toglierti

Ci ritorni.




 Ci ritorni.



Bravo, e` meglio per te. E ribadisco lo "sti cazzi".





Vabbeh.




 importante.



Se non gli fai un esempio concreto, non capisce. Considera che ha il QI 

di un babbuino con problemi.





Che quaraquaqua, ora ti defili e fai gli insulti passando per terzi.

Parli tu poi, che ti invitano pure per le sagre di paese come attrazione.






 Che quaraquaqua, ora ti defili e fai gli insulti passando per terzi.



No, no, io te lo dico direttamente che sei un COGLIONE. D'altronde 

risponderti sul tecnico non serve a niente: non capisci un cazzo. E lo 

hai dimostrato bene molte volte.





Ti piacerebbe.





Due esempi:

1- Inserimento di un nuovo record in tabella con forte concorrenza e che 

può generare errori di chiave duplicata causa contraint per mantenere 

un'univocità di un progressivo per anno per esempio.

Io lo gestisco in una sp con dentro il suo bel try/catch (esempio di 

quelle feature aggiunte lato db nel tempo ma usate pochissimo, è un 

riferimento al grafico postato in alto messaggio), nel catch loggo la 

violazione e rifaccio l'insert. Tutta la complessità è nascosta al 

chiamante.

2- Ottenere un elenco di top N attività in corso con priorità dinamica 

che dipende dal tipo di risorsa umana coinvolta e dal periodo della ricerca.

Io lo gestisco sempre via sp con l'uso delle clausola top dinamica 

offerta direttamente dal db e con abbondanza di cte per rendere 

l'estrazione capibile e quindi facilmente mantenibile.



Ora, in questi due esempi mi spieghi l'utilità dell'io asincrono di cui 

ha accennato da fare sopra al db nel layer dedicato alla bl? Perché 

dovrebbe dare performance migliori?




 ridere



Perche` non le comprendi, ecco perche`. Sei un povero beota abituato a 

fare quattro stronzate.



 l'estrazione capibile e quindi facilmente mantenibile.



Altra cagata che non da` NESSUN vantaggio rispetto all'esecuzione di una 

query.





E' verto, infatti a me mica mi chiamano a far l'attrazione alle sagre di 

paese.




 paese.



Lo vedi che sei un idiota? Non sai neanche scrivere risposte con un 

senso logico. Tu *SEI* un fenomeno da baraccone. Mi piacerebbe davvero 

vederti fare le tue stronzate. Credo che a ridere saremmo in piu` di uno.



 Ma i/o asincrono verso cosa allora?



intendo queste tecniche di programmazione:



http://goo.gl/Hz5xH4


http://goo.gl/eZsxMi




se ti va di approfondire qui c'era un corso di cui forse riesci a 

reperire ancora il materiale molto interessante e ben fatto:



https://www.coursera.org/course/reactive



 dovrebbe dare performance migliori?



a parte la cagata di cui sopra e su cui evito di infierire ulteriorimente 

(sul serio, una stronzata del genere sarebbe da radiazione) ad ogni modo 

ribadisco ti stai incaponendo su un dettaglio. mi fai degli esempi di 

operatività sul database ed è ovvio che l'operatività sul database venga 

delegata al database. il punto è che la business logic di un applicativo 

*solo in parte* è operatività sul database. quindi dovresti essere te a 

spiegare perché delegare al db ciò che *non* è operatività sul db sarebbe 

efficiente. vedi di rispondere anche te a qualche domanda, perché per 

fare 2 + 2 sarebbe più efficiente farlo fare al db invece che 

all'applicazione? 




Passa dal 2+2 ad un altro esempio più realistico.






Ma anche a piangere.






 Ma anche a piangere.



Anche. Effettivamente, quel che scrivi fa piangere.



 Passa dal 2+2 ad un altro esempio più realistico.



2+2 e` un esempio calzante di qualunque processo che non implichi un 

accesso al database. Fai uno sforzo di immaginzione. Ti e` veramente 

cosi` difficile capire che la business logic di un applicativo potrebbe 

non essere semplicemente accesso al database? Se un sistema ha bisogno, 

ad esempio, di validare un codice fiscale con l'agenzia delle entrate, 

se hai bisogno di contattare un server esterno per calcolare una 

particolare tassa, se hai bisogno di segnalare un tentativo di frode, 

ecc... tutto questo non e` logica di business che puoi implementare su 

database.



 Passa dal 2+2 ad un altro esempio più realistico.



tipo gestire un file in upload e il suo parsing, generare dal resultset 

un pdf piuttosto che un excel debitamente formattato, calcolare le rate 

di un piano di ammortamento, calcolare il percorso migliore fra due 

coordinate geografiche. 


 Semplice: il numero e` bruciato. Ed e` giusto che sia cosi`. 



ma anche no. il database è acid, vuol dire che c'è l'isolamento e 

l'atomicità. ergo basta seguire le best practice e non si brucia nulla.




I generatori sono normalmente trasversali alle transazioni. Se usi sequence in Oracle, sei fuori dalla logica delle transazioni. Il numero è bruciato.


Usare una select for update è ovviamente un'altra strada, ma obbliga ad avere una tabella di numeratori.






possibile si, il linguaggio lo permette.



java nasce nel 1995, e grosse aziende, o enti pubblici, prima di 

inserire un nuovo linguaggio all'interno del proprio sistema core 

business, ne passa. non sono certo start-up che utilizzano l'ultimo 

linguaggio, o l'ultima buzz word, giusto per provarla, o che hanno una 

capacità di cambiamento rapida.

ora persone che avevano una esperienza approfondita in tale linguaggio 

erano poche e certo non erano le persone che decidevano (erano persone 

appena uscite dall'università o che avevano fatto corsi specifici).



mettici anche che molte best practices sono venute con il tempo, 

all'eopca che io mi ricordi, non erano ancora usciti i FW per tale 

linguaggio, o erano usciti da meno di 2 anni.



quindi non c'erano neanche le conoscenze approfondite su tale linguaggio.



Ciao










certo che no



rispondevo per chiedere un chiarimento sui sui "principi", e 

scherzosamente ho enunciato l'agile e in quale "principio" avremmo 

peccato :)



siamo ancora alla metodologia spiral, anche perchè prima che qualcosa si 

muova deve essere tutto approvato, firmato, collaudato e bla bla bla..



Ciao


 avere una tabella di numeratori.



eh beh. non sarà certo questo il problema.



No, certo. E` che nella maggioranza dei casi, garantire che non vi siano 

buchi nella numerazione, non e` necessario, e quindi usare un generatore 

va benissimo.



 select[...]for update per acquisire 



Sara' una di quelle feature che gli RDBS hanno rilasciato copiosamente. Non pretenderai mica che le conosca tutte?




Upload, parsing e pdf non li consideravo bl vera e propria, ma contorno, 

comunque se vogliamo mettere tutto quello che non è ui come bl allora 

certo, non tutto lo si fa fare in modo nativo al db, anche se per 

esigenze massive pure li il db si può ben arrangiare a schedulare ed 

inviare in giro per la rete materiale di vari tipo (penso ai reporting 

services su ms sql server).





Simpatico, parla quello che invece i running-totals li calcola con le 

query che durano un quardo d'ora per 4 righe.




 Upload, parsing e pdf non li consideravo bl vera e propria, ma contorno,



Perche` sei uno scemo. Business Logic significa tutto cio` che e` 

"logica di business". Il fatto che tu pensi che tutto possa passare dal 

DB (e magari debba) la dice lunga sul tuo livello di idiozia.





Cazzi miei, insisti ancora su questi toni e divento pericoloso.






Andrea Laforgia dei miei coglioni, il prossimo giro che faccio dalle tue 

parti mi organizzo e vedi che ti calmi per bene.




 fa l'errore di chiave duplicata, se si presenta.



Il semaforo lo fa l'errore? Ma come ti esprimi?


 Cazzi miei, insisti ancora su questi toni e divento pericoloso.



Sei un idiota e, visto quello che fai e come lo fai, puoi essere 

pericoloso solo per te stesso, DEMENTE.



 deadlock sia appunto il codice in transazione.



Quali deadlock? Facci un esempio se riesci. Le operazioni in transazione sono quelle che ti hanno già spiegato:



begin

select for update

insert

update counter

commit


 parti mi organizzo e vedi che ti calmi per bene.



Ha ha ha ha ha... Vieni pure, minorato mentale. Ma tu ci credi veramente 

alle stronzate che scrivi? Che idiota, porca troia.



 ma che significa questa frase?



Un cazzo, come tutto quel che dice il televisivo/trevigiano.





Non è difficile.

Con tabella dei progressivi e select + hint for update il semaforo viene 

fatto bloccando la riga che mantiene il calcolo del progressivo fino a 

fine transazione.

Nell'altro caso la violazione di chiave indica il tentativo di riuso di 

un progressivo già consumato su una insert che si è chiusa e quindi 

segnala la necessità di recuperare un nuovo progressivo.




 Quali deadlock? Facci un esempio se riesci. Le operazioni in transazione sono quelle che ti hanno già spiegato:



Ragazzi, ma voi lo ascoltate pure? E` uno scemo, non sa quel che dice.





Vedi che quando ci si incrocia ci credi per davvero.




 segnala la necessità di recuperare un nuovo progressivo.



I progressivi NON si generano a questo modo, IDIOTA.




Magari in transazione non c'è solo l'insert?




 Vedi che quando ci si incrocia ci credi per davvero.



Quando ci si incrocia, tu finisci prima all'ospedale, e poi in galera ;)



 Magari in transazione non c'è solo l'insert?



LOL :) Sei da lasciar perdere davvero. Povero scemo.





Insisti e vedi che qualcosa lo guadagni.






Ricomincia ad andare per le sagre.


 Insisti e vedi che qualcosa lo guadagni.



Guarda che stai prendendo calci in culo da qualche settimana ormai. Se 

tu avessi un briciolo di dignita`, faresti a meno di comportarti da 

patetico leoncino da tastiera, guappetto dietro uno schermo, e ti 

ritireresti in buon ordine. Continuare ad aggrapparti alle tue 

stronzate, non ti aiuta.





Uaz uaz uaz, sono curioso per davvero.

Poi se sei un quaraquaqua come immagino e viene accompagnato, ah, beh, 

vedi che l'asso nella manica ce l'ho anche io...




On 22/02/2016 21:25, AleTV wrote:



[...]

Cerca su Google cos'e` un "deadlock", COGLIONE.





Qui dentro se c'è qualcuno che si esprime come un mafioso russo con 

l'uccello in tiro in cerca di culi vergini sei esattamente tu.

Io rispondo a tono. Poi tu mi vieni a parlare di dignità, ma che fai 

dalle tue parti, pure il politico?

Ma crepa.




 vedi che l'asso nella manica ce l'ho anche io...



Mamma mia che paura!!! Scusa, mi tremano le gambe! Sento lo stimolo 

urgente di scrivere una funzione scalare per generare progressivi!!!





Emerito pirla, i deadlock su db li traccio da un po' di tempo.

CREPA.




 Qui dentro se c'è qualcuno che si esprime come un mafioso russo



Sei tu, non io. Ti esprimi da bestia repressa quale sei. Ti lascio 

perdere perche` ormai e` chiaro che sei un deficiente incompetente 

arrogante e idiota, che lavora col culo e che pretende anche di 

difendere le proprie "tecniche" indifendibili. Metto il thread in ignore 

e ti mando volentieri affanculo. Continua a risponderti da solo, BEOTA.




Tu non sai neanche cos'e` un "dealock", imbecille. E lo hai dimostrato 

bene in questo thread. Sfoderi la tipica rabbia di chi riconosce di non 

capire un cazzo. Come detto altrove: ti lascio perdere. Continua a 

risponderti da solo.





Vedi che lo trovi quello che prima ti appende al muro e poi ti chiede di 

spiegare un'altra volta cosa volevi dire.






Guarda, altri da smerdare in scioltezza li trovi con facilità, non c'è 

dubbio. Poi però arriva quello che ti fa capire qualcosina che ti 

sfugge, e non lo fa a parole, stai certo. Ma con i bambini a volte è 

necessario.




 services su ms sql server).





Tutto quello che vuoi, ma non sai cosa e' un semaforo.


 I progressivi NON si generano a questo modo, IDIOTA.



Ottimo spunto.

Io come identificativi uso sempre degli UUID; capita però che siano necessari identificativi numerici, e che il 'progressivo bruciato' non sia accettabile. Allora in questi casi la mia soluzione è stata un combinato disposto di:

- sfrutto i campi autoincrement;

- sfrutto le transazioni;

in questo modo, è il DBMS che si occupa di assegnare al momento opportuno il progressivo (in fin dei conti, è progettato per questo!);

- recupero l'identificativo creato.

I DBMS con cui ho avuto a che fare, in un modo o nell'altro, hanno utilità che consentono quest'ultima operazione.

Il problema che mi sono posto - ma non ho mai verificato, non sono mai stato in ambienti in cui ci sono molte transazioni per minuto - è: questo modello funziona se invece il numero di transazioni sale vertiginosamente? Lo dico in altro modo: finora l'approccio ha funzionato alla grande, ma non vorrei che, mettendo il DBMS sotto pressione la cosa crollasse. Capiamoci, nel mio ambito applicativo assai improbabile che capiti, è solo per pura curiosità accademica.



-- 

Ciao!

Luca


 pressione la cosa crollasse. 



non ho confidenza con i db che usano le identity, tuttavia basta guardare 

la documentazione: se le identity sono transazionali e il database è acid 

vuol dire che il meccanismo è garantito, se manca una delle due 

condizioni il meccanismo non è garantito. 

e se una feature è garantita vuol dire che il risultato non dipende da 

quanto intenso è il suo utilizzo. al limite ti dovrai preoccupare delle 

prestazioni.


 I DBMS con cui ho avuto a che fare, in un modo o nell'altro, hanno utilità che consentono quest'ultima operazione.





Guarda che l'autoincrement ti brucia il numerino in ogni caso, proprio come i generatori. Non ho mica capito il combinato disposto di cui sopra...


 Guarda che l'autoincrement ti brucia il numerino in ogni caso, proprio come i generatori. Non ho mica capito il combinato disposto di cui sopra...



Mi spiego meglio. In base alle prove che ho fatto (mi sono limitato a SQLServer e PostgreSQL), se integro tutto in una transazione E do al DBMS il compito di assegnare un identificativo univoco, in caso di un qualunque fallimento di un'operazione che a questo punto, in quanto integrata in una transazione, è paragonabile a un'operazione atomica, al rollback torno alla situazione precedente, e dunque di fatto il numerino non è bruciato.

A me - e, te lo dico chiaro, forse limitatamente a quei due DBMS - la cosa ha funzionato, nelle rarissime occasioni in cui l'ho usata (ripeto, preferisco gli UUID se la situazione suggerisce più comodi identificativi univoci).



-- 

Ciao!

Luca



Ti ripeto: gli autoincrement non funzionano come dici e ti bruciano il numero. E non potrebbe essere altrimenti se ci pensi.




Motivo?

Se una certa transazione viene killata dall'engine perché è stata scelta 

come vittima nel deadlock, viene rieseguita.

E' un approccio comune.




 E' un approccio comune.



non si è mai visto da queste parti un deadlock per via di una insert, mi 

spiace. 

fermo restando che se la tua sessione viene killata crepa come tutte le 

altre. quello che probabilmente non ti è chiaro è che se la sessione 

viene killata non è che puoi catturare l'eccezione e rieseguire lo 

statement nella stessa sessione (killata) come se niente fosse.










 statement nella stessa sessione (killata) come se niente fosse.



Devi applicarti di piu'. Lo so mica e' facile, ma come un testo antico va decifrato lettera per lettera e le parti consunte vanno indovinate.



Se ho capito bene, lui fa il try catch fuori dalla transazione. Sarei curioso di vedere quale giungla di commit try rollback catch ha messo in piedi.



eh ho capito ma se fosse così vorrebbe dire che lo fa lato applicazione, 

non nella stored procedure. crollerebbe tutto il castello... non che 

stesse granché in piedi, però mi verrebbe da chiedere di cosa si è 

parlato finora.



che poi quindi questa fallback insert la farebbe in un'altra transazione? 

per inserire una riga ci sta che faccia anche una rollback? t'immagini 

che roba avere un programmatore che ti sparpaglia di queste bombe nel 

programma, io come menimo gli do fuoco. 




Quello che invece non è chiaro a te a al compare cicap è che, almeno per 

ms sql server, dal 2005 nei try catch si può gestire la rilevazione di 

un errore di deadlock e rifare la transazione rimanendo sempre nella sp 

che non termina manco per il cavolo.

Cosa che fa pure oracle almeno da una ricerca veloce con google.

Se tu e altri siete slegati dal db per gestire ste robe, azzi vostri, io 

e altri le si gestisce nel db.








Rimane tutto dentro la/le sp.

Cos'è, i try catch lato applicativo sono fondamentali mentre lato db 

sono un disastro?

Guardati i try catch che dissemini nel tuo codice.





Nella bl che scrivo io, siccome uso un linguaggio ad alto livello e framework superbi rispetto ai tuoi, posso tranquillamente non fare alcun begin/commit/rollback nel 99% dei casi.



E il retry, se proprio serve, posso implementarlo con JMS (no, non e' "uno strato per gestire tabelle di contatori" cit. AleTV) e configurarlo a dovere. Senza bisogno di begin, rollback commit, try catch e altre porcherie varie.




 che non termina manco per il cavolo.



tu hai scritto che la "transazione viene killata". visto che sostieni di 

esprimerti con la chiarezza di chi sviluppa sul db dovresti sapere cosa 

significa killare una transazione. quando dico che componi frasi 

incomprensibili usando termini a caso te ti offendi ma è così.



ad ogni modo sì, su oracle quando viene rilevato un deadlock viene 

semplicemente sollevata una eccezione. non facendo commit ne rollback la 

transazione rimane aperta. ora se tu dici che catturando l'errore di 

deadlock tu possa ripetere l'operazione pone dei seri dubbi sul fatto che 

tu sappia cos'è un deadlock e come si generi: se tu riprovi ad acquisire 

nella stessa transazione la stessa risorsa che hai trovato bloccata, è 

ovvio che la troverai ancora bloccata e ti pianterai un'altra volta nel 

deadlock. 




Uaz uaz, che poi sono quelle porcherie che alla fine invece arrivano 

proprio al db.






Guarda, se io so poco di dedlock tu ne sai ancora di meno, ovviamente 

non è possibile e non lo ho mai scritto che si può ripetere l'operazione 

nella transazione che è stata scelta come vittima, visto che appunto per 

definizione la transazione non è più in piedi. Come scritto invece enne 

volte, si ripete, ovviamente con un'altra transazione che potrà andrare 

a buon fine, perché l'altra (non quella che è stata scelta come vittima, 

ma quella che il db ha fatto proseguire) nel frattempo i lock oggetto 

del contendere li avrà anche rilasciati perché si sarà conclusa.

Ora, visto che o fai finta di non capire, o non capisci proprio, questa 

è una traccia che sotto ms sql server funzia:



Nella sp principale che gestisce apertura e chiusura della transazione:



set @deadlockRetries = 2

while 1=1

begin

	begin try

		begin tran



		exec dbo.my_spStep1 @p1, @p2, ...

		exec dbo.my_spStep2 @p1, @p2, ...

		exec dbo.my_spStep3 @p1, @p2, ...



		commit tran

		break

	end try

	begin catch

		select @err= error_number(), @errMsg= error_message()

		rollback tran

		if @err = 1205 -- deadlock

		begin			

			exec dbo.my_clrSpLog @spName, @err, @errMsg

			set @deadlockRetries -= 1

			if @deadlockRetries < 0

				;throw

		end

		else

			;throw

	end catch

end

go



Questa invece una traccia per una sp figlia, tipo quella che fa il 

famoso insert, esempio in dbo.my_spStep1:



while 1=1

begin

	begin try

		set @newProg = dbo.tblGetNewProg(@p1, @p2, ...)

		insert into tbl (c1, c2, ...)

			select @newProg, @c2, ...		

		break

	end try

	begin catch

		select @err= error_number(), @errMsg= error_message()

		if @err = 2627 -- chiave duplicata

		begin

			exec dbo.my_clrSpLog @spName, @err, @errMsg	

		end

		else

			;throw

	end catch

end






 Uaz uaz, 



Invece che scrivere uaz uaz, studia che e' meglio. Puoi cominciare googlando JMS ...




Era:



 proprio al db.



Che non significa nulla, da qui il cut. Comunque sono convinto che non e' solo un problema linguistico, e' proprio che hai le idee confuse. Ma tanto.



Anche te non scherzi se pensi che i livelli più alti interagiscano per 

te verso il db usando comandi sconosciuti...

Chissà come mai gestiranno le transazioni, bah, misteri.

Se non usi sql come linguaggio di programmazione, cavoli tuoi, io lo uso 

spesso invece. Le idee confuse son le tue. Continua con i framework 

superbi e divertiti.

Passo e chiudo.




 Passo e chiudo.



Non ho detto che non uso le transazioni, che non uso SQL, che non faccio uso di SELECT, INSERT, UPDATE, DELETE e quant'altro.



Ho detto che i framework possono risparmiarti la fatica di impostare le transazioni manualmente, di compilare comandi SQL e di gestire rollback in caso di eccezioni.



Esiste un mondo la fuori.


 E i perculamenti te li puoi tenere, 



guarda tu non hai neanche una vaga idea dello sforzo che ho fatto per 

tenerli.

anche perchè non credere che non l'abbia capito, ma con tutto questo 

farfugliare in pseudo-tecnichese un po' credi di prendere per il culo.

ad ogni modo la notizia è che anche per questa puntata il tempo a tua 

disposizione è scaduto. 




No problem, il tread sta qui, servirà a qualcuno magari. A chi sceglie 

di usare le sp per far qualcosa di un attimo strutturato e non 4 comandi 

sql in croce.




 E segnati che ho scritto:



Hai riportato cagate, che tra l'altro rootkit ti ha smontato in quattro secondi rendendoti ridicolo davanti a tutto il ng. 



E non si e' ancora capito il vantaggio di rifare la procedura con la SP. Tutta roba che se proprio vuoi farla puoi benissimo piazzarla dentro un metodo Java o quel che vuoi e mascherare il retry la' dentro. 



Poi capisco il tuo punto di vista: tu sai programmare solo stored procedure, e allora tutto il mondo deve usare le stored procedure. Che fa il paio con non sai un cazzo di web quindi il web e' immaturo.



Comoda la vita se fosse cosi'.




Bla bla bla bla.




 PUNTO.



Qualsiasi linguaggio che prevede il concetto di "funzione" ha questa capacita'. Non e' una ragione per spostare logica nella SP.




On Thursday, 25 February 2016 20:37:49 UTC, AleTV  wrote:



<snip>

Giuro che se nel mio team ci fosse gente che scrive codice del genere, la caccerei fuori a pedate nel culo. Che poi, non sai neanche contare i deadlock retries, dal momento che li setti a 2, ma poi esegui i retry 3 volte. 

Ah, quant'e` bello scrivere codice non testato! Sei da licenziare.




Parla quello che se non ha un test dietro non capisce manco cosa fa il 

codice.




 codice.



Tu, purtroppo per te, cosa fa il codice, non lo sai ne` con i test, ne` senza i test.






Ma tu c'hai il premio di produzione collegato al numero di post del 

cazzo che fai nel ng?

Oppure dopo il N+1 volo dalla finestra subito dai colleghi hai dedotto 

che è più salutare sparare cazzate nel ng?

Oppure entrambi! SI! Entrambi!




 viene ripetuta la transazione per errore di deadlock.



Haha...quanto mi diverti :) troll e` quel che sei. Guarda che qui dentro le merde, finora, le hai pestate tu, e ti e` stato fatto presente piu` e piu` volte. E` divertente vederti arrampicare sugli specchi. Il fegato grosso che mostri nelle tue risposte dimostra bene quanto e` difficile per te accettare di essere un incompetente. Ripeto quel che ho detto in passato: sei da licenziare in tronco.



Sei abile nel quotare ma quando la merda è bella grande, non basta mica!

Il tuo premio di produzione comunque è garantito.