Newsgroup: it.lavoro.informatica
Titolo: portabilita' applicazioni

Haila', volevo sapere qualcosa sulle vostre esperienze di
portabilita' (successful o meno..) di applicazioni. Non intendo
riscrivendo il software da zero, ma ad esempio cambiando la
piattaforma di esecuzione per un' applicazione Java,o application
server o cambiamento di database etc...Qualcuno ha avuto avventure/
disavventure in questo campo?

 disavventure in questo campo?
Ultimamento ho portato qualche milione di righe di codice (mission
critical nella sua interezza) in c++ da x86 a x64.
Abbastanza divertente come esperienza :)
Il problema maggiore è stata l'ottusità del servizio clienti
Microsoft, la versione x64 di una loro libreria, usata in 2 righe di
codice, aveva un bug abbastanza evidente ad interoperare con una loro
tecnologia (COM+!), mi hanno fatto perdere 2 mesi a sparare cannonate
al loro muro di gomma (per non dire di tutti i progetti d'esempio che
gli abbiamo sviluppato) prima che ci arrendessimo (abbiamo tolto
l'interoperabilità con COM+
per quelle 2 righe di codice). Altre funzionalità di altre terze parti
le abbiamo potate, ma almeno la risposta è arrivata velocemente (ci
dispiace, non supportiamo x64), e non erano mission critical e/o
comunque non causavano problemi a quasi nessun cliente (in quel caso
ci avremmo scritto un web service di sopra o qualcosa di simile ed
avremmo continuato ad usare la versione x86).
L'altro giorno per caso mi ha invitato a cena un'amica, e tra una cosa
e l'altra mi diceva che aveva qualche problema al notebook. Gli ho
chiesto di farmelo guardare 5 minuti, lo apro, capisco in 3
microsecondi che lavora per Microsoft (la conosco da qualche anno ma
non lo sapevo!). L'ho scampata bella perché in quel periodo ero al
massimo del mio disprezzo per il suo datore di lavoro (non ancora ai
livelli di Apple!), e potevo partirmi con una tirata anti-Microsoft in
qualsiasi momento durante la cena :))
--
ale
http://ale.riolo.co.uk

 l'interoperabilità con COM+
LoL!!! una situazione infernale!

 qualsiasi momento durante la cena :))
Di queste cose, da profano della programmazione, ne vedo ogni santo giorno.
Quello che mi lascia perplesso è la seguente cosa: come si spiega la 
loro esistenza in vita, vista l'assoluta incapacità a gestire i loro 
stessi prodotti/progetti e l'interoperabilità fra di essi?
ah, saperlo...


e' lo stesso motivo per cui la apple fa soldi a palate! :-D



evidentemente non facevano/fanno tanto cagare i loro prodotti
sarà, ma quando devo sviluppare qualcosa su web 
asp.net
 è la mia prima 
scelta. faccio in 5 minuti quel che farei con php in 2 ore.
lo dico avendo Linux su 2 computer/su 2 ...
poi a lavoro si lavora in ambito ms.. quindi ...

 poi a lavoro si lavora in ambito ms.. quindi ...
Dove lavoro io anche e per questo ne vedo tante.
Lungi da me giudicare, ma il problema esiste, per cui saranno 
sicuramente bravi....in qualcosa... :)

 disavventure in questo campo?
a me è capitato qualche cambio scambio  Oracle / SqlSever / Sybase.
Non ricordo particolari problemi, certo c'è stato da lavorare anche
sull'applicazione, ma più che altro mi ricordo un lavoro noioso fino
all'infinito, non per il codice o il lavoro, quanto per le procedure
di  migrazione dati ed il test.. due cose che se vuoi fare bene con
piani di lavoro e documentazione su progetti che già funzionano non
sono proprio esaltanti.

 sicuramente bravi....in qualcosa... :)
Se lavorano in com, com+, vb6 e simila hanno ragione i programmatori,
quella roba sulla carta era bellissima ma nella realtà è uno schifo.
Invece, de lavorano in .net e tecnologie recenti... da profano della
programmazione quale sei  dovresti cominciare a dubitare del manico,
di solito il problema sta lì.

 sono proprio esaltanti.
Un buon codice non si tocca a fronte di una migrazione db.
Come sempre c'e' in giro codice di cioccolata scritto al risparmio/spreco e
giustamente si pagano le conseguenze nella situazione descritta da te.
Ciauz Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

> Un buon codice non si tocca a fronte di una migrazione db.
Eccola. Questa mi mancava !
Ma di la verità, non fai il programmatore non ci credo.. che sistemi
fai per lavoro ? Dai, dimmi un po. Secondo me insegni...

 fai per lavoro ? Dai, dimmi un po. Secondo me insegni...
?????????????


 Un buon codice non si tocca a fronte di una migrazione db.
è una fesseria. Il buon codice può stare addirittura dentro il DB,
tutto è relativo allo specifico dominio del problema e della
soluzione, l'idea del one size fit-all nelle architetture è stata una
sciagura.

 Detto questo  :


Mah, ho fortissimi dubbi su chi gha detto la fesseria
E' da 14 anni che lavoro in proprio, in consulenza, da dipendente, per
PMI, per multinazionali, pubblico e privato, e ogni tanto insegno pure (
spero non ci sia qualcosa di male a insegnare ... ), e il codice di norma
e' db cross.
Quando non lo e' ci sono dietro i soliti architect farlocchi, manager che
hanno preso sole, ignoranza e via dicendo.
Ci sono rarissimi casi in cui si deve scrivere in dialetto di un database,
ma sono davvero rari e in Italia quasi inesistenti.
ciao Nicola
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ma sono davvero rari e in Italia quasi inesistenti.
Assolutamente no. Un cross DB costa di più. Se l'azienda ha scelto un
DB allora può sfruttarne a pieno le caratteristiche (aka stored,
feature particolari o altro ) per sviluppare in modo più veloce ed
efficiente.
Questo non è vero per il pacchettizzato medio piccolo ma anche li non
è detto, sposare un DB porta innumerevoli vantaggi ma un prezzo da
pagare sulla portabilità.
Dire che un buon codice è multi DB è una generalizzazione inutile, un
po' come dire che le buone auto sono quelle che vanno a gpl e benzina,
non è vero, è un vantaggio, ma c'è un prezzo da pagare e degli
inconvenienti.
Un buon codice può anche essere in RPG su AS400, se l'azienda ha
deciso di usare AS, eppure non mi sembra che sia per così dire
facilissimo farlo girare su Oracle.
ecco il mio punto.

 ma sono davvero rari e in Italia quasi inesistenti.
Spero di no :)
Altrimenti come si potrebbero giustificare i 30-40 mila Euro a
processore spesi per Oracle? ;)
--
ale
http://ale.riolo.co.uk

 ciao Nicola
1. Essere cross platform lato server non è un dogma, se le specifiche non
lo prevedono è stupido privarsi delle caratteristiche proprie del DBMS che
si deve utilizzare
2. In tanti anni di onorata carriera non ti è mai capitato di dover
scrivere un trigger o una stored procedure, che dipendendono totalmente dal
dialetto del DBMS ?
E come mi gestisci il fatto che, per esempio, in TSQL la concatenazione di
stringhe si fa con il + e in PostgreSQL con || ? 
Oppure che in TSQL per convertire un valore null usi isnull e in PostgreSQL
coalesce ?
Da qualche parte nel tuo codice (chiamalo DAL o in altro modo) ci sarà pure
una condizione che dica al flusso esecutivo che istruzioni usare. Se devi
essere cross platform lo prevedi fin dall'inizio, altrimenti la situazione
la devi gestire dopo, ma la *devi* comunque gestire.
PaF

Il Fri, 19 Nov 2010 19:43:43 +0100, PaF ha scritto:
[cut]
...a meno di usare un ORM, che ti fa il lavoro "sporco", ma che IMHO non
sarà mai efficente come il codice che puoi scrivere tu se conosci bene la
tua piattaforma di riferimento.
PaF

 ma sono davvero rari e in Italia quasi inesistenti.
Questo e' un punto interessante e che si sente ripetere spesso, ma uno
dei motivi che mi ha spinto a scrivere questo post e' che comincio a
dubitarne. In particolare c'e' gente ( e non cazzoni qualsiasi ma del
calibro di Thomas Kyte) che sostiene che la portabiita' su diversi DB
sia possibilie solo in situazioni molto semplici, perche' ad esempio
sulle varie piattaforme DB i meccanismi di locking e in generale la
gestione della concorrenza funzionano in maniera diversa.. Ora, e
ovvio che chi come lui e' un iperspecialist su una qualche piattaforma
db proprietaria veda come il fumo negli occhi la "trasparenza del
db" (in sostanza lo rende inutile..) ma qualcosa di vero credo che ci
sia..

 Spero di no :)

Non c'e' correlazione diretta.
Moltissimi architect  e testi sono favorevolissimi all'uso di Oracle per
vari motivi, su cui si puo' anche discuterne, pero' sono tutti contrari
all'uso di dialetti db, all'uso di stored, trigger e quanto altro s enon
in casi estremi.
Il motivo e' che l'applicazione degrada in modo forte con danni alla
manutenzione, aggiornamento, evoluzione, porting, integrazione, danni di
tutti i tipi che ovviamente si pagano in denaro.
Al contrario di cio' che scrive Equinozio una applicazione dialettale
costa DI PIU' di una cross sull'intero ciclo di vita.
Tanto per scendere un po' piu' in dettaglio e parlare di campi in cui mi
muovo da anni, l'intero JEE e' sostanzialmente cross db per natura e
incompatibile con le stored e le view. Qualsiasi architect JEE ( 100% d
quelli che ho conosciuto o letto ) non ha il minimo dubbio su cio' perche'
progettare una applicazione dialettale vorrebbe dire escludere
sostanzialmente il JEE.
E stiamo parlando della tecnologia piu' diffusa al mondo nel campo
enterprise.
Anche non usando JEE nel 2010 esistono 1000 alternative per fare
applicazioni portabili e senza dialetti e mi auguro che non ci siano molti
folli che spingono le stored dove non servono ancora oggi.
Ovviamente questo non vuole dire che un developer stored sia di serie B,
tutt'altro, massimo rispetto, come si rispetta un developer assembler,
probabilmente piu' di un jee,  cio' non toglie che l'assembler si usa in
casi rarissimi e i trigger pure :-)
ciao NIcola


 non lo sapevo!). L'ho scampata bella perch� in quel periodo ero al


 PaF


 la devi gestire dopo, ma la *devi* comunque gestire.
Quello che dici e' tutto vero, a parte l'uso delle caratteristiche 
proprietarie su cui non sono completamente d'accordo, anche se spesso si 
possono utilizzare dei costrutti standard ISO SQL che bene o male sono 
accettati da tutti i DB, io ad esempio, uso sempre il verbo CONCAT, che 
di sicuro e' meno snello dell'operatore, ma funziona "sempre" (diciamo 
che non mi e' ancora capitato che non funzioni), poi dire che anche 
coalesce, standard sql92, funzioni anche su sql server.
Mentre nel codice non mi capita proprio mai di dover indirizzare delle 
istruzioni di un db o un altro, in genere uso strumenti tipo iBatis o 
Hibernate, mi capiterï¿œ di dover duplicare un file-map in fase di 
installazione e correggere qualcosa qua e la', ma il codice non ne sa 
niente.
-- 
Dr. Ugo Gagliardelli, Modena, Italy
Spaccamaroni andate a cagare/Spammers not welcome

 Un buon codice non si tocca a fronte di una migrazione db.
le affermazioni assolute tendono sempre ad essere sbagliate.

 ancora via SW,
Secondo me non è solo questione di efficenza ma di studiare un'architettura
magari complessa, ma sempre pulita.
Perché scomodare un trattore (ORM) quando per fare la stessa cosa puoi
utilizzare un rastrello (stored o trigger) ?
Io da questo punto di vista ammetto di essere old style, ma se appena
appena posso evito di aggiungere strati di astrazione su strati di
astrazione, sui quali oltretutto avrei poco controllo degli "internals".
PaF

 traduce in micro-secondi e' richiesta rarissimamente e quasi sempre si
Micro secondi ? Ci sono procedure che girano l'intera notte su DB
server da favola e mi parli di microsecondi ? Quando devi processare
qualche milioni di righe che coinvolgono qualche centinaio di tabelle
ti voglio proprio vedere ad un usare soluzioni esterne al DB.
Ma anche una semplice procedura transazionale per una PMI da 100.000
righe che  risolvi in 20 secondi di elaborazione lato server voglio
vedere su hibernate quanto ci mette.
Poi certo puoi spiegare al cliente che ha ordinato una procedura
custom per LUI per calcolare l'inventario che si...  ci mette 2 ore ed
un quarto, che si... il sistema vecchio in AS di prima ci metteva 5
minuti, ma sai... questo è multiDB !

 le affermazioni assolute tendono sempre ad essere sbagliate.
Io leverei il "tendono" e lo sostituirei con "sono".
(si, già lo so che poi la preposizione "ad" poi non torna e qualcuno
me lo farà notare)

 astrazione, sui quali oltretutto avrei poco controllo degli "internals".
Se stiamo facendo una semplice applicazione la tua domanda puo' essere
legittima, possiamo usare cio' che ci aggrada, oggi un trigger, domani un
orm, dopodomani uno script language e tris domani ritiro fuori il vecchio
caro C++.
Di fronte a un applicativo di una certa dimensione, che durera' 10 anni o
piu', ci lavoreranno magari nel tempo anche 50 persone, magari verra'
spostato rivisto eccetera, non e' che possiamo andare cosi' a sensazioni e
decidere tirando una moneta se e' meglio il trattore o il rastrello.
L'archiettura deve essere PULITA, in modo tale da sapere come e dove
metterci le mani, i deploy devono essere altrettanto semplificati, i testing
anche, le integration anche, i parametri di configurazione centralizzati,
ecc ecc eccc ( solite manfrine da libri ma non e' che li scrivono solo per
metterli negli armadi i libri :-) )
Uun paradigma pressoche' indiscutibile e' che se non ho prblemi gravi di
prestazioni e TOLGO la logica dal db avro'
-) Tutta la logica nell'appserver ( o qeul che uso )
-) Tutta l'applicazione scritta nello stesso linguaggio
-) Il deploy unificato normalmente su un 'unica macchina
-) se entra uno nuovo nel team avra' meno difficolta' a capire dove sta il
codice perche' sta tutto nello stesso posto ( = maggiore leggibilita' )
-) Facilita' di integrazione perche' di nuovo ho tutto nello sytesso punto
-) Parametri centralizzati
-) debugging centralizzato
-) clustering spostato probabilmente fuori dal db
-) Attori coinvolti semplificati, infatti tipicamente il dba e' diverso dai
sistemisti di deploy
-) sicurezza semplificata. Un deploy in produzione di Stored procedure e'
differente da undeploy di classi o similari
...............
-) il cross db sinceramente e' una feature comoda ma tutto sommato neanche
cosi' primaria a meno che non sto pacchettizando.
In questo scenario, che copre un'enormita' di situazioni, il codice nel db
e' evidente che inquina come la diossina. Chi ha lavorato su progetti di
questo tipo lo sa.
 pur se tutti sappiamo che e' piu' potente, meno ce ne e' meglio e'.
Senza aggiungere che se devo scegliere chi buttare giu0' dalla torre fra il
trigger e l'ORM non ho il minimo dubbio, e ricordiamo che la soluzione
mista e' malatissima e quindi se si parte con le stored adios ORM.
ciao Nicola


 minuti, ma sai... questo &#65533; multiDB !
5 minuti a 2ore e un quarto ?????
vabbe lasciamo perdere, mi pare impossibile discutere di fronte a queste
cifre
il discorso mi pare che diventa sterile, guardati in giro e vedi quanti
architect oggi preferiscono le stored ad hibernate per applicazioni
aziendali classiche ......
auguri


 questo tipo lo sa.
Ma anche no.
Comunque buon per te che hai tutta questa sicurezza, io sono abituato a
valutare i pro e contro in modo meno dogmatico.
PaF

 ciao NIcola
Andrea 

 ti sei lasciato guidare dal compilatore ? hai seguito delle linee guida ?
All'inizio sě, poi ho scoperto il sito dei ragazzi di Tula, che č stracolmo 
di ottimi suggerimenti (
http://www.viva64.com/en/l/
), anche se non gli 
compri il software (BTW, va molto oltre i suggerimenti, se lo provi č 
effettivamente difficile evitare di farci un pensierino, soprattutto se ci 
devi lavorare a lungo o su molti progetti: 
http://www.viva64.com/en/order/
).
-- 
ale
http://ale.riolo.co.uk
 

 PaF 

 folli che spingono le stored dove non servono ancora oggi.
BTW, in generale non sono contrario a tutto quello che hai scritto, anzi.
Nella vita quotidiana mi scontro con stored o peggio spezzoni di sql 
costruiti combinando stringhe in C++ (stile if (bIsOracle) sSql = 
bstr("yadayada ... else if (bIsSqlServer) yadayada....) scritte spesso un 
decennio fa (con la sintassi Oracle con i + per direzionare i join), per cui 
tocco proprio con mano :))
-- 
ale
http://ale.riolo.co.uk
 

 Io leverei il "tendono" e lo sostituirei con "sono".
Visto che ti piacciono cosi' tanto i confronti dialettici, mi spiace ma
qui ti ha fregato lui in quanto la tua e' un'affermazione assoluta e
quindi hai affermato esattamente il contrario di quello che volevi
inizialmente esprimere (esempio perfetto di ironia). :-)


 disavventure in questo campo?
a me e' capitato da SQL2000 a SQL2005 ; c'era del TSQL che non dava errori 
di sorta ma rallentava vistosamente. Il codice era abbastanza lungo, ma 
spezzandolo in piu' parti si trovo rapidamente l'inghippo.
Mi e' -quasi- capitata una migrazione da VB6 a Vb.NET ; dico quasi perche' 
in realta' habbiamo rinunciato alla 'migrazione' e l'abbiamo riscritto :-) 
pero' era un caso 'anomalo', un programma abbastanza grande (10000 righe di 
codice) ma molto semplice.
Ora che ci penso, questo programma aveva anche un altra (piacevole) 
anomalia; e' iniziato molti anni fa e nel corso del tempo sono state 
aggiunte molte funzioni (mi dissero che la versione iniziale leggeva da un 
file di testo su disco, faceva certe operazioni con le stringhe e scriveva 
un altro file di testo) ed e' stato ampliato / mantenuto da almeno 4 miei 
colleghi che mi hanno preceduto ; eppure era scritto bene, con commenti 
aggiornati ecc ecc . Spero di aver continuato su quella strada e vbisto che 
mi sono licenziato ... spero che ci lavora oggi non mi mandi troppe 
maledizioni :-)

 costa DI PIU' di una cross sull'intero ciclo di vita.
Ma a parte queste frasi fatte, hai qualche dettaglio in più o case history
*che non coinvolga porting* che dimostra quanto affermi ?
Se all'inizio del progetto si sposa una determinata tecnologia e si è
sicuri di mantenerla (per me è il mondo Microsoft) ritengo in realtà che
sia dannoso proprio il fatto di non sfruttare il più possibile quanto c'é
di buono nella tecnologia scelta.
Sono d'accordo se invece le specifiche possono prevedere che in futuro
l'ambiente di esecuzione possa cambiare, ma - ripeto - non tutti i progetti
enterprise hanno questa esigenza.
PaF

 aziendali classiche ......
Già, quanti ?
Please nomi e cognomi, perché detta così è solo una frase fatta senza alcun
fondamento.
PaF

 Se e' batch  tipicamente lavora di notte.
No, ci sono molte procedure che devono essere lanciare di giorno ed
essere praticamente interattive e lavorare su grosse moli di dati. Se
non ti sono mai capitate... beh non so che dirti.
Il che non vuol dire che non si può fare senza stored, tutto si può
fare con tutto, ma che costi 10 volte di più e che serva un hardware
molto superiore è un fatto.
E torniamo al punto, la qualità come valore astratto non ha senso, il
buon codice è quello che risolve il problema, è manutenibile, con
pochi errori ed economico. La portabilità è un valore solo se è un
requirement, e questo vale anche per i linguaggi ed ambienti di
sviluppo, una azienda ha tutta la convenienza a scegliere una
piattaforma e sfruttarla fino in fondo.
Teorema d'Equinozio :  La migliore architettura del sistema è quella
più adatta al raggiungimento dei requirement all'interno dei
constraint. Tutto il resto è fuffa.

 -) Il deploy unificato normalmente su un 'unica macchina
Sinceramente io lavori in ambienti ben più eterogei, dove il DB è il
cardine del sistema
Poi :
- Le applicazioni sono scritte in linguaggi diversi
- Da Team diversi
- Su macchine diverse
- In tempi diversi
- In luoghi diversi
- Con contratti e metodi diversi
- a volte su DB diversi
a far da collante spesso uno strato di interfaccia proprietario o
anche no.
Se invece il sistema è uno piccolino per fare la gestione di una
finaziariasu SqlServer + .net, usati senza inutili complicazioni e
strati intermedi da manutenere/aggiornare e studiare, ci sanno
lavorare tutti dopo 1/2 giornata di formazione. Stessa cosa con php +
mysql.
PS: mai e dico mai avuto problemi nel rilascio di stored, fanno
insieme agli script del DB non ci vedo niente di trascendentale.

 qui ti ha fregato lui in quanto la tua e' un'affermazione assoluta e
Colpito ed affondato.
hahahahahahaha!! Sei un grande !

 anche no.
L'architettura perfetta che sognano tutti e fa risparmiare ...
sui testi scientifici la chiamano di norma "spaghetti integration" :-))



te l'ho detto che insegnavi :-) Sui testi scientifici c'era scritto
che il rischio di default si distribuiva ed il rischio default per i
fondi immobiliare USA era quasi zero.

 efficiente.
mah. il 99% (a stare stretti) delle volte in cui una azienda chiede (o 
meglio, impone) allo sviluppatore di realizzare le proprie procedure sul 
db è perché è l'unico modo che conoscono di fare integrazione. per la 
serie: se la scrivo su una store procedure son sicuro che qualsiasi 
tecnologia capace di connettersi al database lo potrà invocare.

 traduce in micro-secondi 
Ho un caso sotto mano che ti smentisce.
Una stored procedure scritta in T-SQL faceva si che il sistema di
analisi che avevo messo in piedi richiedesse 3 giorni per due milioni
di record (un sistema di calcolo di somiglianza stringhe...)
Trasformata in stored procedure CLR richiede circa una trentina di
minuti.
Sicuramente la prima e' infinitamente più portabile della seconda. Ma
il cliente non aveva alcuna voglia di aspettare tre giorni per
un'analisi...
-- 
Ciao!
Luca

 tecnologia capace di connettersi al database lo potr invocare.
Hai detto niente ! Perché l'azienda dovrebbe rinunciare domani ad
usare ruby per il sito aziendale, .net per il gestionale e php per chi
sa cos'altro ?

 utilizzare un rastrello (stored o trigger) ?
Non sei "old style", sei "MS Style". E' un fatto che chi sviluppa in
Java ha da sempre una preferenza per la logica di business
nell'applicazione, non fosse altro perche' tutti i javisti (seri) sono
puristi object oriented e desestano PL/SQL o T-SQL, mentre i "MSistii"
usano da sempre interfacce grafiche che fanno chiamate a stored
procedures su SQL Server. Non sto dicendo che un approccio sia in
assoluto migliore dell' altro, ma che esiste di fatto questa divisione
(anche se credo vada scemando, con l'arrivo di EF per esempio..)

 (anche se credo vada scemando, con l'arrivo di EF per esempio..)
gli EF hanno moltissimi svantaggi, il primo è che sono mono
tecnologici.

 giustamente si pagano le conseguenze nella situazione descritta da te.
Oppure è codice che sfrutta a fondo le caratteristiche specifiche del
db (es. hint di ottimizzazione delle select). Cosa che, secondo me, è
sacrosanta: sfruttare bene il db che hai oggi, senza inutili
preoccupazioni di quello che accadrà tra anni.
L'esempio più "bello" di codice massimamente portabile/migrabile sono
le librerie GUI Java. La AWT (si chiamava così?) era così portabile
che .... l'hanno rapidamente buttata nel cestino per quanto era
inefficiente :-))

 tua piattaforma di riferimento.
Oppure usi standard nel codice SQL, tipo quelli ANSI, e nulla più.
Oppure usi uno strato di accesso tipo ODBC.
Gli ORM li lascerei per ultimi, se li sono dovuti inventare per
forzare a martellate la progr. OO sui DB relazionali. I quali ultimi
manco per la capa sono stati soppiantati dai db OO, come avrebbero
voluto i fans OO.

 voluto i fans OO.
ORM  che poi vengono usati per lanciare stored e select con il
passthru dopo averci sbattuto la capa forte ma forte forte...  perché
va detto e ripetuto senza vergogna, almeno qui.
E visto che il passthru l'ho visto fare su un bel progettino da
qualche milioncino di euro farcito di tanti bell'esperti java, ibm, e
dell'integrator, tutti a riempirsi la bocca di astrazione e poi a
lanciare i passthru... perché se no un gli funzionava un C.... Ma in
riunione dal cliente.. Eh si.. noi usiamo XXX ! Noi siamo
indipendenti ! Si indipendenti dalla realtà!! 2 anni 20 persone per
fare 100 maschere di inserimento dati, al rogo dovrebbero andare !
Ma per favore: getting real, tutti gli strumenti possono essere utili
o disutili ed hanno un loro giusto ambito.

 [...]
Ciao  Manlio

 sa cos'altro ?
ma infatti mica ho detto che la problematica di integrazione non esiste, 
ho detto che quella è l'unica soluzione che conoscono.

 clienti.
A meno di features specifiche disponibili solo su particolari database
(vedi PostgreSQL con PostGIS per i dati spaziali, SQL Server ne ha aggiunto
il supporto solo con la versione 2008).
PaF



Paf daiiiiiiiii, non mi pare che sei uno che deve per forza dare contro.
Quello che dice Root ( per ora stranamente in modo molto pacato :-)) 
e che nella NORMALITA' delle situazioni, delle banche, delle industrie,
delle assicurazioni, delle PMI, nella NORMALITA' ripeto NORMALITA'
dove per NORMALITA' si intende percentuali altissime di casi, 90-99 %
i clienti si scelgono uno degli N db gratis-a apgamento o quelli che
vogliono a loro pieno diritto.
Sempre in questa benedetta NORMALITA' e' conveniente 
1. Per una SW house avere SW db independent, per riciclo, per evitare di
avere 800 programmatori diversi, per evitare di tagliarsi fuori da certi
clienti eccetera e per i 1000 altri motivi per cui mi sto pigliando
dell'insegnante , che non so come mai al giorno d'oggi pare sia peggio di
essere un pirla :-)
2. Per un cliente avere sw db independent comuqnue gli garantisce una
qualita' complessiva piu' elevata ed evitare l'architettura incubo di
Equinozio, che ha detto di avere sw sparpagliato a casaccio a volte dentro
il database di una marca, a volte dentro il database di un'altra delle N
marche, a volte in un layer propietario, a volte in un linguaggio, a volte
in un altro, a volte su una macchina, a volte su un'altra, e la mattina si
tira la moneta per decidere come e dove lavorare :-)
3. Poiche' sempre nella NORMALITA' dei casi il 99% delle query su db sono
< 1 secondo e se serve una stored ogni 1000 query NORMALI nulla vieta di
metterla comuqnue.
-----SEGUE------> 
che nella NORMALITA' dei casi un architect sano di mente, una SW house
sana di mente, un cliente sano di mente, cercano di evitare il suicidio e
se non ci sono controindicazioni utilizzano tecnologie il piu' trasparenti
possibili. 
Se poi  la sua applicazione necessita per forza di PostGis e dei i dati
spaziali io gli consiglierei un antimalocchio o un prete :-))))
Ciao Nicola


 di progetto? in questo caso alzo le mani, il committente ovvio che non
Solitamente lavoro per il committente.
Ma anche nei software che faccio "per me" preferisco vivere senza
multi DB, tanto i DB con cui lavoro sono 2 : Oracle e SQlserver e dove
c'è Oracle spesso c'è pure un angolino scuro con SqlServer, a dire il
vero si trova praticamente ovunque, è gratuito, quindi non vedo il
problema. Poi al limite si converte, non è certo impossibile.

possibili.
L'architettura che tu chiami incubo è la realtà delle aziende grandi,
nulla di strano avere più prodotti software con diverse architetture
che coesistono, altrimenti tutte le tecnologie di middleware non
esisterebbero.
Detto questo se la scelta tra multi DB e mono DB fosse equivalente o
quasi, anche io ti direi si, è meglio il multi DB.
Solo che non è così e lo sviluppo su più basi dati costa nella mia
esperienza almeno il 20-30% in più, anche solo per la duplicazione di
ogni test, di ogni rilascio ogni script di modifica del DB ecc.. e non
dirmi "ma i test nell'altro DB non si fanno" perché allora anche le
mie sono multi DB a meno di qualche stored.

"Net_Byt" <Andrea-Z...@TOGLIMIhotmail.it> ha scritto nel messaggio 
news:4ce6fe88$0$34311$4faf...@reader3.news.tin.it...

e con questo si dimostra quanto sia lontano il mondo reale dall'informatica 
"teorica"
a livello universitario.
Bella la discussione sulla "indipendenza delle applicazioni dal database" ma 
temo
che stiamo dissertando sul motore a ioni dell'astronave che andra' su 
Marte...
mentre poi,  per tornare stasera a casa,  useremo la Panda col 1200cc a 
benzina...:-)
ciao
fm 

facilissimo farlo girare su Oracle.
facilissimo? io mi domando se sia possibile...
RPG senza AS/400 (meglio sarebbe dire senza  IBM) ...e' come un pesce fuor 
d'acqua...
ciao
fm

 problema. Poi al limite si converte, non è certo impossibile.
intanto due è già maggiore di uno. poi nessuno parla di impossibilità e 
tu stesso hai citato i costi come problema. infine, fingi di non sapere 
che il problema non è la migrazione ma il *dopo*, cioè quando avrai il 
doppio dei costi da sostenere per il supporto.

 o disutili ed hanno un loro giusto ambito.
quoto 

 il supporto solo con la versione 2008).
ma niente ti vieta di non porti nessun problema e presentare il prodotto 
con il suo database, ma questo non vuol dire che i problemi che non ti 
poni non esistano. per esempio, se il tuo programma oltre che trattare 
coordinate geografiche dovr� garantire un certo livello di servizio e il 
cliente ha gi� una infrastruttura db diversa in ha, qualcuno dovr� 
convincere il cliente a dotarsi di un'altra infrastruttura in ha. oppure 
se ci dovesse essere necessit� di integrazione fra il tuo programma e i 
dati del cliente, oppure fra i programmi del cliente e i tuoi dati, 
qualcuno dovr� spiegare al cliente che le "stor prosidur" non gli 
risolvono il problema. insomma nulla � impossibile, ma pi� ti poni 
inflessibile � pi� hai bisogno di essere commercialmente forte.

 inflessibile è più hai bisogno di essere commercialmente forte.
Certamente, e rispondo anche a n.n, non è per fare il "bastian contrari".
Il fatto è che - per esempio e applicando la discussione ad un mio caso
pratico - se avessi voluto scrivere una mia applicazione GIS ponendomi come
obiettivo il multi db non avrei avuto comunque scelta, nel 2007 l'unico
server database open source di un certo livello che aveva il supporto ai
dati spaziali era postgresql. Puoi spostare tutta la logica di accesso ai
dati dove vuoi, ma poi ti scontrerai con il fatto che per fare query
spaziali i comandi sono quelli di postgis.
Quando è uscito SQL Server 2008, che ha il supporto ai dati spaziali, mi
sono posto il problema se mi conveniva fornire il supporto anche a quella
piattaforma, ma ad oggi la risposta è ancora no, perché postgresql lo puoi
infilare dove vuoi visto il basso footprint che ha, SQL Server è un mattone
e devi avere un server quasi dedicato.
Io non sono certo contro il multi db, ma a differenza di n.n non credo che
sia l'unica via e che sviluppare con una precisa scelta di campo sia una
opzione da percorrere solo raramente, visto che la mia esperienza dice il
contrario.
Poi ognuno si gestisce i clienti come vuole, basta che il risultato sia
quello voluto dal cliente e che noi si guadagni :-)
PaF

 contrario.
non per sminuire la tua esperienza ma se tu stesso parli di "features 
specifiche" stai dicendo che sei l'eccezione, non la regola.



beh spero che al mondo non si sviluppino solo gestionali
fatture/magazzino/produzione :-)
PaF

 disavventure in questo campo?
Non e' un vero e proprio problema di portabilita', ma
come dicevo in altro post, una delle ultime applicazioni sviluppate qui e'
stata una web application che utilizzava jboss su linux con dbms mysql ma
poi in produzione si e' usato sempre jboss ma su Sun Solaris con dbms
Oracle. Problemi non ce ne sono stati (l'applicazione era stata sviluppata
usando hybernate).
In passato (molto passato: 1999-2000) mi era capitato di esportare su web
dei dati (di un calzaturificio)prelevati da un sistema as400 con
un'architettura un po' strana, ovvero i file venivano presi (dalla
macchina as400 remota) e trasformati in un db db2 che mi ritrovavo in
locale, poi venivano portati da db2 a MySQL (reingegnerizzandoli. Il db
db2 aveva tabelle con 120 campi di cui gli ultimi 90 rappresentavano tutte
le coppie "pellame-colore" con cui poteva essere prodotta la scarpa
individuata dal codice articolo che era sostanzialmente la chiave
primaria).
Da MySQL (su linux) venivano presi i dati ed esportati sul web utilizzando
Zope.
Grossi problemi non ce ne furono
Ciao,
Marco.


 vogliono a loro pieno diritto.
Tra l'altro, quali sarebbero gli N db tra cui scegliere per
applicazioni di un certo livello? Me ne vengono in mente solo 4: DB2,
Oracle, SQL Server e Postgres.
Un numero così piccolo da rendere ancora più improbabile il cambio del
db entro una prospettiva realistica di progettazione. Per realistica
intendo che nessuno può immaginare quali saranno le specifiche di un
db tra 5-10 anni. In altre parole, oggi puoi usare tutte le accortezze
di progettazione che vuoi, ma tra 5-10 anni il prodotto sarà comunque
vecchio.

 vedere su hibernate quanto ci mette.
Non so quanto ci metterebbe senza hibernate, ma un paio di settimane
fa mi e' capitato proprio un caso di questi: una applicazione stand-alone
scritta con Hibernate e' stata lanciata e ha elaborato circa 100.000
record (erano circa 117.000, anche se poi quando parte non e' detto che
trovi sempre lo stesso numero di record nel db: fa una query del tipo: 
SELECT campo,count(*) FROM tabella WHERE <data compresa nel mese
precedente a quello in cui viene lanciata l'applicazione> GROUP BY campo
e poi elabora le righe ottenute una ad una formattandole opportunamente e
scrivendole in un file [che uno script dovra' poi spedire in sftp su una
macchina remota]).
Ci ha impiegato circa una trentina di secondi, compresa la scrittura su
file.
Il DBMS (remoto) era Oracle 10. La macchina era Sun Solaris, abbastanza
"carrozzata" (tipo 32G di RAM).
Ciao,
Marco


 incontrato uno
Eccomi!
Va beh.. in realta' non posso certo definirmi "programmatore assembly",
ma mi e' capitato di studiarmi  l'assembly per i processori Alpha della
Digital (oltre che l'assembly per il 286 che ti insegnavano
all'universita') per scrivermi qualche piccola parte di codice che serviva
a caricare del codice su una scheda DSP. E' vero l'ho usato solo per
piccole cose e ormai 12 anni fa, pero' l'ho usato!


 ah, saperlo...
Come diceva John Smith (a proposito di altro argomento), l'importante non
e' saper fare bene qualcosa, l'importante e' saperlo vendere!
E come diceva invece il mio docente di Reti Logiche all' universita' (a
proposito sia dell'assemblatore Microsoft che a proposito dell'arhitettura
dei processori Intel): "tutto cio' che e' tecnicamente 'fatto male' ha un
enorme successo a livello commerciale"


 sicuramente bravi....in qualcosa... :)
Si'. A vendere, sono imbattibili!


"carrozzata" (tipo 32G di RAM).
Su una macchina del genere qualunque cosa è veloce.

 vecchio.
Figa se e' dura discutere qua dentro :-))
Abbiamo detto e stradetto tutti che siamo tutti d'accordo che il cambio db
non avviene pressoche' mai.
Si dibatte di altro.
Ciauz


 Si dibatte di altro.
Scusa ma in realt� avevo capito di parlasse proprio di questo.
Se non si prevede in futuro anche solo lontanamente di cambiare db cosa
piffero mi frega di spaccarmi la testa a scrivere codice cross platform ?
:-)
PaF

 fatture/magazzino/produzione :-)
e perché la problematica di fare uso più o meno intenso di database
relazionali è peculiare dei gestionali?
se il tuo programma salva dei dati rilevanti su un database e il
cliente ha già una infrastruttura db amministrata, backuppata e in ha,
sarà pure logico che lo faccia su questo database invece di introdurne
un altro che dovrà essere a sua volta amministrato, backuppato e
magari anche in ha. no? fatto salvo eccezioni e casi particolari,
ovviamente. o forse non ho capito a che ti riferisci...

 :-)
forse perché il committente può non cambiare mai il database, ma tu
fornitore puoi avere più committenti...

 piffero mi frega di spaccarmi la testa a scrivere codice cross platform ?
NOn ti spacchi nulla, ci sono N strade, alcune ti danno frale altre cose
il multidb.
ciao NIcola


 
Addirittura! Nonostante lavori in Java (e non mi possa certo definire architect
- anche se qualcosina credo di capirci) non sono assolutamente convinto che JEE
sia il silver bullet, anzi. Se si parla dell'architettura complessiva di JEE
posso anche essere d'accordo (è un casino e spesso, per fare una cosa
semplicissima, ci vogliono giornate intere), ma per quanto riguarda l'uso di
ORM, non è che ci siano solo in Java: per Ruby ce ne sono almeno tre, per Python
non so quanti e così via. 
E' ovvio che bisogna sempre tenere conto dei requisiti, della mole di dati e di
un sacco di altri parametri, ma molto spesso un ORM semplifica la vita a tutti.
Poi, ognuno può avere le proprie opinioni - come è giusto che sia (ad esempio,
ritengo che, di massima, il db debba fare da storage, e che i dati vadano
manipolati fuori dalla base di dati e che il modello relazionale sia decisamente
limitante).
In ogni caso, una discussione interessante :-)

 fornitore puoi avere più committenti...
Si vero, ma ero convinto si parlasse di sviluppo custom, non di software
pacchettizzato (per il quale l'approccio multidb è chiaro anche per me),
anche perché nel caso di n.n pensavo che l'applicazione decennale fosse "su
misura".
PaF

 relazionali è peculiare dei gestionali?
Attenzione, ho scritto "gestionali fatture/magazzino/produzione", non
gestionali generici. Quindi mi riferivo ad un caso diverso rispetto al
discorso standard, ma non credo così "eccezionale".
Nel mio caso ho scritto un gestionale in ambito GIS, deve quindi trattare
dati associati a record spaziali, con query di ricerca spaziali etc etc
Quindi oltre al dato "standard", per il quale qualunque tipo di database
andrebbe bene, devo associare tipi di dati che sono supportati solo da
alcuni database, e ognuno nel proprio modo. 
Il multi db "trasparente" in questo contesto è ancora difficile, almeno per
quanto ne so (se non fosse così apprezzo ogni suggerimento, si discute
anche per imparare).
Con questa premessa se il cliente è interessato alla mia soluzione si
adatta ad aggiungere postgresql nel suo parco software, oppure si attacca
(ed io con lui).
PaF

 poi a lavoro si lavora in ambito ms.. quindi ...
Mi spiace per te, sul serio.
Greetings
JOKER Ltd.

 :-)
Si vede che hanno cambiato al volo argomento, con un giro di email
segrete :-))

 ovviamente. o forse non ho capito a che ti riferisci...
Senz'altro la problematica dei prodotti software da vendere a N
clienti è di questo tipo. Il pacchetto deve essere aperto a diversi db
(in verità spesso ma non sempre, anche qui dipende dagli obiettivi).
Però allora è improprio parlare di migrazione.

 Poiche' la soluzione ibrida e' da evitare ci si trova di fronte alla
Beato te che trovi sempre problematiche così indubitabilmente bianche
o nere :-))

 fuori dal db.
Che poi non è affatto detto. Ci sono funzionalità che stanno nel DB,
altre che vengono esposte come servizio con un layer di
disaccoppiamento, in alcuni casi di interfacce complesse è preferibile
portare fuori la logica perché renderebbe impossibile fare le stesse
cose con il DB.
In sostanza la regola è che non c'è una regola fissa, l'importante è
scegliere lo strumento adatto e non usarlo per fare quel che non è
stato progettato a fare. Quindi un sistema di web service e porte tcp
va bene per un documentale distribuito, ma non va bene per i report,
l'application server con un ORM va bene per un ecommerce, ma non va
bene per un sistema molto più complesso, il multi DB va bene per SAP,
ma un po' meno per il cliente che paga per qualcosa per lui inutile.
Io i casini li ho visti solo quando si prende a martellate una
architettura per fargli fare quel che non è stata progettata a fare,
tipo le stored per creare l'html e i web service per disaccoppiare UI
e logica in maschere interattive.. ogni click una post back ed un
chiamata di web service in http.. no dico ma ce ne saranno di modi
migliori ??

 o nere :-))
Magari. Avete una facilita' a trarre conclusioni errate durante le
discussioni che fa spavento, vabbe che e' iun forum-bar pero' dai
cerchiamo di tenere su un dibattito un po' serio.
Quando vado in giro in Body Rental ne vedo di tutti i colori. Piu' di una
volta le query sai dove le ho trovate ? Nelle JSP !!!!!!!!! altro che
dialetti DB. Ed ero su aziende fra le piu' grosse in assoluto d'Italia.
E comuqnue piu' di una volta ho lavorato in PLSQL, dobbiamo pure mangiare.
Un'altra volta ho trovato un architect deficente che ha messo hibernate e
poi ha fatto TUTTE le query in view native del db e stored, le
barzellette. E ancora sosteneva di avere ragione e che era l'architettura
giusta.
Il fatto e' che in Italia nelle grandi aziende tipicamente c'e' una
qualita' cosi' bassa che viene da piangere.
Qua stiamo discutendo su quali siano le architetture migliori di fronte
alla varieta' dei DB. A livello di discussione e' piu' facile trvare il
bianco e il nero. 
Se un progetto lo imposto io cerco di evitare che vada a finire cosi' e
metto su una buona architettura. Per il resto mi tocca come tutti
sguazzare nella *****.
i progetti in giro li hanno impostati i soliti architetti che chissa' dove
hanno studiato, che non hanno esperienza, che sono raccomandati, che sono
finti. ( hai visto ieri report ? :-( ) )
This is Italy :-)
Comqunue non e' tutto cosi', ci sono molti che stanno facendo bene.
ciao Nicola


 il multi DB va bene per SAP,
ecco, preciso. fra migliaia e migliaia di esempi giusti quando si dice
andarsi a cercare proprio quello sbagliato... :P

rootkit ha scritto:



Ma lolllllll davvero.
Se non le sfrutti sui mega ERP le stored  .....
N


 Se non le sfrutti sui mega ERP le stored  .....
più che altro che sap sia un esempio di "multidatabase"...

 andarsi a cercare proprio quello sbagliato... :P
E che vi portavo un esempio a favore !?
Questa è logica partigiana :  SAP = Multi DB  quindi  Multi DB =
Prodotto come SAP :-)

 migliori ??
SU questo concordo, i webservice per il disaccoppiamento li ho dovuti
usare e per ogni virgola da cambiare c'e' un overhead di lavoro da
piangere. 
ciauz
N


 Prodotto come SAP :-)
Ma tu l'hai mai visto uno schema/database SAP? :)))))
--
ale
http://ale.riolo.co.uk

 sparpagliata qua e la'.
Ma il lavoro di chi gestisce l'architettura è proprio quello di
gestire questa complessità e fare le scelte giuste, non è quello di
applicare un modello/architettura fissi, magari perché conoscono
quello e fare tutto con quello. Ovvio che sarebbe bello fare tutto
nello stesso modo con le stesse tecnologie con la stessa struttura..
ma i requirement hanno la priorità sulle regoline che ci diamo noi
programmatori. Se no facciamo la fine dei sistemisti che bloccano gli
allegati superiori a 1Mb..
Poi per dire, ho visto programmi vb6/access che sembravano rebus
inestricabili e sistemi con più DB e più tecnologie che interagivano
dove non perdevi un istante a capire dove cercare il codice
incriminato.
Secondo teorema di Equinozio : non è che architettura usi, ma come la
usi.

 un articolo che hanno venduto un millisecondo prima succede un casino
Sono ignorante in materia, ma pensavo che Hibernate fosse in grado di
gestire in automatico il lock del record che ti serve. Se "e' stato
venduto un ms prima", quando vai a loccarlo lo dovresti trovare gia'
loccato (se e' in fase di completamento della vendita) oppure lo dovresti
trovare nello stato "venduto" se la vendita precedente e' gia' stata
effettuata (se e' nel carrello di un'altro, cosi' a occhio e croce
dovrebbe essere o in uno stato "non accedibile" oppure comunque, se anche
possono metterlo nel carrello in 2 contemporaneamente quando vai a
venderlo dovrebbe valere uno schema di accesso del tipo
lock
se non e' venduto
{
vendi
imposta stato a venduto
}
unlock 
)
Ciao,
Marco


 finti. ( hai visto ieri report ? :-( ) )
Spesso il problema non è che il singolo architetto ha fatto tutto lui,
sbagliando. Il problema è che ci si sono "applicati" svariati
architetti e pseudo tali in differenti epoche (talvolta molto
ravvicinate, pochi mesi; tal'altra molto distanti come vere ere
archeologiche).


please rootkit (o n.n. o chiunque) dite qualcosa anche a chi non ha mai 
lavorato su SAP, almeno sapremo se parteggiare per l'uno o per l'altro :-)

 Su una macchina del genere qualunque cosa è veloce.
ottimista ! non hai visto certe query che ci son in giro ;-) 

il 29.11.2010 17.52, Scrive Net_Byt 62532288:

Il DB di SAP non si tocca. Se devi fare delle transazioni su SAP, 
dovresti usare una delle funzioni registrate (BAPI), se non ce n'e' una 
che ti vada bene, la si crea, dopodiche' la si puo' utilizzare in modo 
multiforme: in modo nativo, via webservices, via JCO (una sorta di 
object broker per le BAPI SAP)
-- 
Dr. Ugo Gagliardelli, Modena, Italy
Spaccamaroni andate a cagare/Spammers not welcome

 ottimista ! non hai visto certe query che ci son in giro ;-)
LOL
Anch'io, ho visto (e vedo) query che loro umani non possono nemmeno
immaginare :))
--
ale
http://ale.riolo.co.uk