Newsgroup: it.lavoro.informatica
Titolo: Blue Monday ovvero delle domande alle 17e50 che ti fanno...

Scenario: il cliente e' lo spin-off finanziario di una importante realta'
commerciale italiana. 
C'e' da rifare tutto o parte, da capo o quasi un sistema
informativo/informatico, dalle fondamenta al tetto.
A contendersi la gara ci sono due diverse soluzioni, e quando dico diverse
intendo diverse.
Una basata su tecnologia Power IBM (a.k.a. AS/400) con DB2 come rdbms, linguaggi
RPGILE per il back-end, php per il front-end, e' sostanzialmente in continuita'
tecnologica ed operativa con la vecchia casa madre.
 
L'altra soluzione in competizione adotta ORACLE come rdbms, PL/SQL per il
back-end e sempre php per il front-end, la piattaforma tecnologica di
riferimento e' sostanzialmente una qualche forma di virtualizzazione di sistemi
*AIX.
 
La scorsa settimana presentazione delle buste con progetti ed offerta economica,
questa settimana presentazione live dei progetti.  
 
Alla fine della giornata, salutandoci, il CEO del potenziale cliente mi fa':"Ma
insomma mica ho ancora capito bene quale differenza ci sarebbe tra Oracle e
DB2...rispiegatemela un po'...".
 
Giuro, ho visto consulenti fare harakiri cercando di tagliarsi le vene con gli
spigoli di un Sony Z1.
 
Saliut'. 

 DB2...rispiegatemela un po'...".
 
In effetti, dal suo punto di vista, potrebbero essere equivalenti in 
termine di risorse, affidabilità del fornitore... insomma qual è la 
ragione profonda per cui dovrebbe scegliere una soluzione?
 

 DB2...rispiegatemela un po'...".
 
La domanda potrebbe essere interpretata in vari modi. Diciamo che fra le 
millemila cose che sarebbe stato possibile chiedere questa è forse la 
più semplice a cui rispondere... anche se magari non al termine di una 
gara che immagino sarà durata mesi...
 
Cosa gli avete risposto?
 

 gara che immagino sarà durata mesi...
 
Mi sa che lo scoramento è proprio dovuto al fatto che è il genere di domanda la cui risposta è difficilmente comprensibile per un CEO, e, a mio modesto parere, non dovrebbe neanche interessargli. 
Cosa gli spieghi? Il process model? L'affinità o meno del linguaggio SQL agli standard ANSI? Andiamo... dal suo punto di vista, sono prodotti che devono svolgere un lavoro (la persistenza dei dati) e lo fanno entrambi in maniera tutto sommato similare. Sono entrambi prodotti largamente diffusi e ben supportati (sì, le differenze le conosco, ma non facciamo guerre di religione, dai). 
Quello su cui lui avrebbe dovuto decidere è: quanto mi costano? che tipo di termini di servizio mi offre il fornitore per il supporto? Ci sono differenze concrete nelle spese operative, nel capacity management,ecc.
Io penso che la funzione del consulente IT in questi casi sia proprio di tradurre peculiarità derivanti da caratteristiche tecniche in parametri che siano di immediata comprensione per i "decisori" non IT...
 
Bye!


Ma l' AS400 è ancora vivo ?
 
Comunque nessun dubbio,a parità di applicativo la soluzione Oracle su 
unix e piu flessibile e scalabile
Inoltre Oracle è piu conosciuto di DB2 e questo da piu possibilità di 
trovare esperti su questo nel caso servisse
Stessa cosa per unix
 
 
Per quanto riguarda DB2 (che conosco poco) non credo che possa 
rivaleggiare con il re dei DBMS (che invece conosco molto bene)
 
 
 

> Mi sa che lo scoramento è proprio dovuto al fatto che è il genere di domanda la cui risposta è difficilmente comprensibile per un CEO, e, a mio modesto parere, non dovrebbe neanche interessargli. 
 
Quoto. Ognuno ha il suo lavoro, nel dettaglio a lui non interessa e, cmq, non ha conoscenze per giudicare
 
Al3x


Beh, allora la risposta da dare e' molto semplice:
 
"La differenza e' che DB2 costa X, Oracle costa Y"
 
Vuoi scommettere che qualsiasi CEO comprende questa risposta, 
specialmente se al posto di X e Y ci metti gli effettivi costi.
 
Ciao,
Marco.
 
 

 Ma l' AS400 è ancora vivo ?
 
Aaahh non chiederlo a me, io non ho mai capito come
facevano/fanno gli utilizzatori di codesti sistemi
a non farsi venire l'orticaria con quelle interfacce
testuali stile ante-preistoria informatica.
 
 
 

 specialmente se al posto di X e Y ci metti gli effettivi costi.
 
Peccato che non comprendono gli stessi meccanismi di costi
quando si tratta di ospitare in alberghi 5 stelle e ristoranti
ultra-chic i magnagger amici e i magnagger clienti.
 
 


ma qui non si tratta di "a parità di applicativo", siamo di fronte due stack
completamente diversi.
quanto a oracle dico una sola cosa: quando un marchio arriva
oltre un certo livello di notorietà può fare ai clienti le peggio angherie che
questi subiscono e dicono pure grazie.


 
Guarda, se fosse per me al CEO proporrei postgresql
Scalabile e puo fare molte cose che fa anche oracle e va benissimo per 
la maggior parte dei clienti
Ma essendo gratuito immagino che non lo vogliano
Ma comunque oracle resta sempre il re dei dbms.
 

 non interessa
 
invece di solito avviene l'esatto contrario, ovvero i clienti valutano la
soluzione applicativa sulla base della marca del database. 
 
questo avviene in particolar modo con oracle, "ce l'abbiamo già in casa" è il
ragionamento-tipo. 
 
salvo poi un giorno, quando arrivano "quelli della oracle" con i loro script
per la verifica delle licenze, accorgersi di aver legato mani e piedi 
dell'azienda a degli squali che gli chiedono conguagli milionari, forti di un
ufficio legale senza pari.
 
solo con quella fattura davanti il ceo di turno si rende conto che la storia
del "re dei dbms" è una polpetta avvelenata preparata ad arte.  

>>>>  
http://www.bb2002.it
 :)  <<<<<
........... [ al lavoro ] ...........

 Ma l' AS400 è ancora vivo ?
 
Più che l'AS400, ora PowerIBM, la domanda la farei per RPG. Al suo confronto il Cobol pareva roba da fantascienza :-)

rivaleggiare con il re dei DBMS (che invece conosco molto bene)
 
ahhh...ok solo ignoranza...


Perche', su unix non puoi fare programmi vt-100, magari con curses?
Ti garantisco che in giro ce ne sono parecchi, praticamente tutti quelli 
che risalgono a prima del '90.
L'effetto è grosso modo lo stesso (interfaccia a caratteri) con la 
differenza che il protocollo 5250 e' molto piu' evoluto del vt-100, 
forse è anche per questo che è più longevo e viene ancora utilizzato.
Poi, se su as400 (che vorrei far notare essere un server) vuoi fare 
programmi server-side, lo puoi fare esattamente con le stesse modalita' 
e linguaggi (.net a parte), di qualsiasi altro server.
 

 rivaleggiare con il re dei DBMS (che invece conosco molto bene)
E allora come fai a dire che e' piu' flessibile e scalabile?
 
Quello che poi dire di certo, e' che e' piu' scalabile verso il basso, 
nel senso che Oracle lo puoi installare anche su una workstation Intel 
monoutente, o come db embedded di una singola applicazione. Se parliamo 
del DB2/400, non lo puoi fare, ma se parliamo del DB2/luw puoi fare 
anche questo.
 
Sul fatto che di esperti Oracle ce ne siano di più, hai sicuramente 
ragione, la richiesta di esperti DB2/400 e' praticamente nulla: e' un db 
che semplicemente va, senza bisogno di continue manutenzioni ed 
ottimizzazioni. Volendo potrei essere anche piu' preciso, ma sarebbe 
un'inutile polemica.
 


Tra "correre" e "scappare" non puoi fare dei gran distinguo!
:-))
 


 
Mi spiace per il CEO
 
 


Non mi dire che si usa ancora l' RPG :)
 

Pių che l'AS400, ora PowerIBM, la domanda la farei per RPG. Al suo confronto il Cobol pareva roba da fantascienza :-)
 
mah guarda...in verita se parliamo di back-office di "gestionali", di grosse
mole di dati, fino all'altro ieri esistevano solo cobol e rpg, ieri e' si e'
seduto al tavolo java, oggi ancora nessun'altro (o meglio c'e' una minima quota
di C++ e C#, ma parliamo di quote a livello di prefissi telefonici quindi
ininfluenti nel nostro ragionamento)
 
Pero' sono curioso: tu, oggi come lo realizzeresti il backend di un
"gestionale"? 


 
Puo darsi, magari oggi si è portato in pari con oracle
 
 


Ci si abitua come piu o meno ci si abitua a tutto
 
Per alcuni usi poi,applicativi poi l' interfaccia testuale (quella tipo 
curses) e la piu adatta e veloce rispetto alla GUI grafica alla windows
 


Infatti, ho scritto non credo
Se qualcuno se ne sa di piu su db2 si faccia pure avanti
 

 testuali stile ante-preistoria informatica.
 
devo ancora vedere, se è per questo, un utente ben addestrato che riesca a battere in velocità di inserimento con un'interfaccia point&click un utente di pari addestramento che usa un'interfaccia "preistorica"... ma ribadisco che non mi sembra il caso di fare partire l'ennesima flamewar, restiamo sul punto: come far valutare due offerte comparabili ad un decisore non tecnico? Alla fine, se non si riesce a dargli un input concreto, gli unici fattori resteranno il prezzo e la parlantina del venditore di turno (non sto scherzando). 
 
bye!

Puo darsi, magari oggi si è portato in pari con oracle
 
imvho lo e' sempre stato, non si e' mai scelto l'uno o l'altro per motivi
strettamente tecnici...

 Deve forse essere gratis ?
 
no, non sto dicendo che debba essere gratis. sto criticando la politica
commerciale e l'ingenuità dei clienti che (perdonami) ci cascano giudicando
"giusto" usare oracle come piattaforma su cui appoggiare tutto, perché tanto
"ce l'ho in casa". 
salvo poi accorgersi *dopo* che così facendo gonfiano i costi delle licenze
fino a livelli fuori da ogni raziocinio, milioni di euro appunto. 
purtroppo su questa fessacchionaggine dei clienti la oracle ci gioca e 
parecchio. 


Oddio, ricordo che l'RPG dei bei tempi ti obbligava a scrivere istruzione in una certa colonna-gruppo di colonne, operandi in un altra, ecc. Almeno col Cobol potevi scrivere come ti pareva (nel range 8-72 ;-)
Ma si è di certo evoluto. Infatti oggi lo usano come lanciarazzi anticarro :-))

 "gestionale"?
 
Sul backoffice (o batch) secondo me è molto questione di quale piattaforma si usa, e se c'è molto "legacy". Per esempio, Oracle ti vende il "suo Cobol", il PL/SQL (come infatti hanno messo nella proposta), e se non c'è troppa eredità da convertire può essere una scelta giusta.
In ambito IBM penso che una recente versione di Cobol OO potrebbe essere competitiva con Java (parliamo di batch). Tuttavia l'uso di due linguaggi così diversi (Cobol per i batch, Java per l'online; oppure RPG e Php in questo caso) è un problema organizzativo non da poco. Sia come necessità di gente con conoscenze ben separate, sia come maggiore difficoltà di riusare parti di software da batch ad online e viceversa (esempio: un particolare calcolo di stipendio, che parte batch ma un bel giorno vogliono esporre online per qualche motivo).
Non c'è dubbio che Java ti può coprire entrambi i ruoli, sia pure con dei compromessi.


per mandare avanti le aziende vincenti,
come abbiamo fatto negli ultimi 25 anni ... :-)
 
 
"Solo cio' che piace diventa tradizione" (cit.)
 
ciao
fm 
 
 

 Volendo potrei essere anche piu' preciso, ma sarebbe un'inutile polemica.
 
Sarebbe invece interessante avere un'infarinatura sull'argomento.


La mia era solo una battuta. In effetti RPG in ambiente ILE si e' 
evoluto parecchio, nel senso che oggi RPG-free, permettendo istruzioni 
di calcolo non posizionali, assomiglia al C dei bei tempi andati!
:-)


A disposizione.
Per tornare ai termini di valutazione che avrebbero essere messi a 
disposizione del CEO, le procedure di backup/restore su db2400 si 
riducono ad un singolo comando, che comprende sia db che applicazioni.
Tutto cio' riduce all'osso i tempi in cui i dipendenti si grattano 
aspettando la disponibilita' del sistema informativo. Ovvio in assenza 
di un sistema di High Availability, che pero' implica altri fatti.
 
In caso di disaster-condition, quindi ripartenza con server ex-novo, i 
tempi di ripristino dipendono unicamente dalla mole dei dati, se il 
restore va a buon fine, sempre con singolo comando, sono matematicamente 
certo anche della consistenza dei dati e relativi applicativi. Nel caso 
di as400, la procedura di ripristino totale (ex-novo) del sistema la si 
potrebbe scrivere con un pennarello anche grosso sull'etichetta della 
cartuccia dei salvataggi.
E' cosi' anche per Oracle e relativo OS ospite?
 
Questo enorme vantaggio dipende essenzialmente dal fatto che db2400 e' 
"annegato" nel sistema operativo: se il sistema operativo e' integro, 
allora lo e' anche il db. Questa considerazione dovrebbe mettere in 
evidenza il contrabbandato vantaggio di Oracle di essere indipendente 
dal sistema operativo, ma se ci si pensa non puo' essere cosi': 
semplicemente, la responsabilita' di creare le condizioni di consistenza 
tra OS e db, e' demandata al padrone del vapore. E lui paga!
 
 
 


 
Se la metti su questo piano, buona fortuna all' AS400



 
 
lo usai circa una 15 di anni fa
Alcune cose nelle query erano o limitate o assenti rispetto ad oracle
Ricordo ad esempio che le subquery erano assenti
Viste materializzate e database distribuiti idem
E altre cose di cui non ricordo ora
 
 

 E altre cose di cui non ricordo ora
Magari i tuoi ricordi di 15 anni fa' si riferiscono ad un as/400 che 
all'epoca aveva gia' una decina d'anni, ipotesi plausibilissima, vispo 
che nel db2/400 V4 (seconda metà anni '90) le subquery c'erano.
Per cui cosa vale l'esempio che fai?
Per quanto possa ricordarmi, le subquery erano presenti nello standard 
SQL92; al contrario di Oracle, che si comporta un po' come Microsoft, 
IBM segue gli standard in modo pedissequo, almeno quelli mandatory,  e 
li dichiara anche; poi aggiunge le proprie estensioni per chi le vuole 
usare.
Se volessi essere altrettanto disonesto, potrei affrettarmi ad 
affermare, senza tema di smentita, che in Oracle manca il tipo 
autoincrement, che c'e' addirittura in ms-access.
Ma a cosa vale?
 
 
 

 tra OS e db, e' demandata al padrone del vapore. E lui paga!
 
Bè, ora estremizzi :-) Nel senso che l'indipendenza dal sistema operativo di per sè non è mica un guaio. Certo poi realizzarla al 100 pc nella pratica non è banale.
IBM in realtà ti vende un sistema completo: hw, s.o., dbms, editor, compilatori, ecc. ecc. ed anche l'antenato degli application server, ovvero il Cics :-) (Su mainframe. Su AS400 ci sarà ugualmente, ma non so come si chiama).
Così facendo acquisti sistemi robustissimi, ottimizzati, attentamente retrocompatibili, ma ti leghi integralmente all'azienda "blu" (che comunque i suoi prodotti non è che li regala :-). Quindi come sempre pro e contro.
 
PS: non ho notizia di virus informatici attaccati a mainframe o mini, altro ottimo argomento per sceglierli 

 E' cosi' anche per Oracle e relativo OS ospite?
 
diciamo che con la virtualizzazione ci si va abbastanza vicini, almeno al
ripristino del sistema guest.


Certamente, ma dipende molto dal tipo di disastro. Se banalmente si 
fotte un raid, vabbe'. Ci sono disastri ben diversi.
Nella mia zona, tra terremoto e due alluvioni i disastri erano ben diversi.
Ad un mio cliente, tanto per citare un altro genere di disastro, hanno 
rubato tutte le macchine che hanno trovato al CED.
Ha chiamato un broker che provvisoriamente gli ha consegnato un as400 
usato, ed in poche ore e' ripartito con tutte le applicazioni. Per 
rimettere insieme la "server farm" ci ha messo una settimana.
 

 fotte un raid, vabbe'. Ci sono disastri ben diversi.
 
si, si, sono d'accordissimo. la mia era una osservazione molto a margine.

 notevolmente piu' blando.
 
e più corretto, aggiungo io.

 non per as400.
 
 
Appunto. Di questi tempi un valore aggiunto da sottolineare dieci volte nelle proposte commerciali.
 
 


 
 
L' autoincrement è una grossa cagata
Oracle e postgresql hanno  le sequence che è molto meglio
 

 Oracle e postgresql hanno  le sequence che è molto meglio
 
postgres ha il tipo serial a supporto.
in ogni modo vedo che continui a esprimerti per sentenze ("oracle è 
il re dei dbms", "l'autoincrement è una grossa cagata") anziché per argomenti.
così è difficile andare avanti.
 

 PS: non ho notizia di virus informatici attaccati a mainframe o mini, altro ottimo argomento per sceglierli
 
questo però è un valore più nel marketing che nel tecnico. 
si sa che il problema dei virus riguarda di fatto un solo sistema, ma sappiamo
anche che non è affatto l'unica criticità riguardo alla sicurezza dei dati 
aziendali e nemmeno la più importante.


Non ho nessuna voglia di spiegarne i motivi
O ci arrivi da solo a capire altrimenti lasciamo stare
 


Sarà, comunque è un punto in più, non certo in meno. E potremmo aggiungere altri elementi, ad esempio la memorizzazione in EBCDIC piuttosto che nel molto più noto Ascii, i protocolli per i terminali (TN3270) piuttosto del molto più noto TCP/IP. Saranno anche piccoli elementi, ma ti danno un vantaggio a costo zero nei confronti dei ladri di dati (i ladri non troppo evoluti ed informati, chiaramente). 

 rimettere insieme la "server farm" ci ha messo una settimana.
 
 
Cavolo ! Lo sai che è il mio incubo? L'ho avuto più volte, ricevere la 
chiamata che si sono fottuti i server e che occorre ripartire da zero....
 
 
 

 E potremmo aggiungere altri elementi, ad esempio la memorizzazione in EBCDIC piuttosto che nel molto più noto Ascii, 
 
ma dai... 
 
 


guarda che non c'è assolutamente nulla da capire, se non le motivazioni 
dei tuoi pareri. al massimo viene fuori che esprimi dei pareri immotivati, 
sai cosa me ne frega. 


Come preannunciato voleva essere solo un esempio di provocazione. 
Puntualizzando posgresql ha il serial e se lo gestisce da solo, sintassi 
della DDL a parte, e' esattamente equivalente ad un campo ad uso 
identity. Ho volutamente citato Oracle perche' la sequence è u oggetto 
da creare e da gestire in un trigger, che dal punto di vista funzionale 
e' un po' piu' laborioso.

 e' un po' piu' laborioso.
 
 
Perchè quello quello affermi è un falso
Per usare le sequence non occorrono trigger (in oracle ovviamente)
 
 
 

 Per usare le sequence non occorrono trigger (in oracle ovviamente)
 
se quello che afferma è falso allora spiega qual'è l'altro modo per avere
l'equivalente di una colonna autoincrement in oracle?
 


Non ha scritto quello che affermi tu ma solo questo:
 
 
la sequence è u oggetto da creare e da gestire in un trigger, ..
 
 
compresso l' errore di sintassi (copiato paro paro)
 
 
Certo che se si vuole implementare una autosequence in oracle occorre un 
trigger di riga su insert, ma come avevo già accennato non serve
Anzi, potrebbe essere pure deleterio in sviluppi futuri
L' unica applicazione che mi viene in mente come uso dell' autosequence 
puo essere una colonna che tiene l ordine temporale di inserimento,ma 
naturalmente non è obbligatorio un trigger,basta chiamare la sequence
 
 
 
 
 

 trigger di riga su insert, 
 
appunto.

 Per usare le sequence non occorrono trigger (in oracle ovviamente)
Ciavèdi.
 


 
 
Intendevi la costruzione delle autosequence, non avevo capito
Ma tu hai specificato  sequence  che è un oggetto ben definito e non è 
una autosequence.
 
 
 

 una autosequence.
Veramente le sequence le hai tirate fuori tu per confutare che Oracle 
non dispone di autoincrement.
Evidentemente Oracle e' il classico re travicello.
 


Le sequence le ho tirate fuori per fare capire che l' autosequence è una 
cagata pazzesca ( cit. sulla corazzata potiomkin in un  film su 
Fantozzi) altro che re travicello
 
 

 DB2...rispiegatemela un po'...".
 
il CEO del potenziale cliente, da buon CEO, ne sa di informatica più o meno
quanto mia madre. 
Difatti, se chiedi bene a mia madre la differenza tra Oracle e DB2 ti 
risponderebbe esattamente alla stessa maniera: ma che differenza c'è?
 
fine del racconto.

 Fantozzi) altro che re travicello
 
che è un po' come se dicessi citando le viste dimostro che gli snapshot sono una
cagata pazzesca. 
 
come al solito spari un giudizio assoluto, ovviamente non lo sai argomentare, 
e per tirarti fuori dalla melma vorresti far credere che il tuo giudizio è
lapalissiano in quello che hai già scritto. no, non è così,
purtroppo per te non stai dialogando con gente che non ti può seguire.
 
per inciso io non sono nemmeno uno che ha una particolare simpatia per le
chiavi primarie surrogate, però a volte servono. e in quei casi, dove non
me ne frega nulla del valore ma mi basta sia univoco, l'autoincrement farebbe
comodo visto che lo devo surrogare con le sequence.


La tua implementazione di "far capire" e' alquanto singolare.
Da cosa si sarebbe dovuta dedurre questa chiassosa "cagata pazzesca"?
 


 
 
 
Quando faccio una affermazione di tipo tecnico so sempre quello che dico
Che non ne abbia spiegato i motivi non significa che non li so argomentare
 
 
Un bel gg il tuo database si espande, occorre una nuova tabella in 
relazione 1=>n con la tua vecchia tabella
 
Per il resto fai tu
 
E' un esercizio interessante
 


Segui la mia risposta a rootkit visto che mi avete risposto in due
 

 E' un esercizio interessante
 
in che senso? non ho mica problemi a fare una tabella in relazione 1=>n 
se occorre. dov'è che, secondo te, dimostrerei di essere in difficoltà?


 
 
Non ho affermato che non è risolvibile con solo le autosequence
Tu prova ve suoi e postami una tua soluzione
Poi ne possiamo discutere
 

 Poi ne possiamo discutere
 
scusa sei ubriaco?
la soluzione te l'ho già postata, se ho bisogno di fare una tabella in relazione
1=>n la faccio. che altro ti serve come risposta il ddl?
 
ps: io farei anche basta. 


 
Non intendevo le create table ma l' inserimento nella 2 tabelle
Postare due insert non mi sembra che ci voglia troppo tempo
 

Il 26/01/15 14:43, enoquick ha scritto:

immagino qualcosa come questo (vado a memoria)
 
select id into :id from FINAL TABLE (insert into T1 (C1, C2, ...) values 
('value_1', 'Value_2', ...));
 
insert into T2  (C1, c2, c3) values (:id, 'Value...', 'Value...');
 
 
 
oppure
 
insert into T1 (C1, C2, ...) values ('value_1', 'Value_2', ...);
select IDENTITY_VAL_LOCAL() into :id from sysibm.sysdummy1;
insert into T2  (C1, c2, c3) values (:id, 'Value...', 'Value...');
 
 
 


 
 
E questa è l' insert
Piu corto è cosi:
 
insert into T2(IDENTITY_VAL_LOCAL(),...)
 
 
 
in oracle usando una sequence si fa cosi:
 
 
insert into T1(seq.nextval,....)
 
 
insert into T2(seq.currval,....)
 
 
 
 
La soluzione oracle rimane la piu flessibile;
la sequenza è un vero e proprio oggetto su qui e possibile controllare 
varie cose altre al fatto che è possibile avere piu oggetti sequenza
 
 
 
 
 
 
 

 insert into T2(seq.currval,....)
 
no, non si fa così.
o meglio, se fai così sei un seminatore di bug ambulante.
 
non c'è alcuna garanzia che in quella sequenza la chiamata alla curval 
restituisca il valore della precedente nextval. nessuna. è sufficiente 
che un altra transazione si inserisca incrementando la sequence e vedi
che botti.
 
ma ti dirò di più: se due transazioni facessero la stessa operazione di
cui sopra in concorrenza riusciresti ad ottenere il simpatico effetto 
di agganciare il figlio al padre sbagliato. poi vallo a debuggare quando
il cliente ti telefona per dirti che a volte, ma non sempre, si ritrova
delle righe negli ordini sbagliati. ed è giustamente incazzato come una
biscia.
 
e meno male eri quello che sapeva quello che diceva.
 
 


 
Saluti
--
http://www.linkedin.com/in/stefanotassi
 
http://stefanotassi.blogspot.it
 
 
Programming  today is  a race between software engineers  striving to
build  bigger and better idiotproof programs, and the Universe trying
to produce  bigger and better idiots. So far the Universe is winning.
(Rick Cook)


 
in sql standard
 
si fa una transazione
 
START TRANSACTION;
begin transaction
o altro comando che ti mette a disposizione il dbms.
 
 
insert into T1 (bla, bla, bla) values (bla , bla, bla) returning id into 
:id;
o altra metodo messo a disposizione dal dbms per ritornare un valore.
 
insert into T2 (id_padre, bla, bla, bla) values (:id, bla, bla, bla);
(ripete la chiamata a insert T2 le volte necessarie)
 
end transaction;
 
 
 
puoi anche utilizzare una sequenze, cosa che trovo ormai obsoleta.
 
nel 99% dei casi una sequence viene utilizzata a mo di autoincrement in 
concomitanza con un trigger before insert.
un autoincrement lo trovo più agile, soprattutto quando devi fare un 
clone, o portare una tabella da un ambiente ad un altro o fare il merge.
 
in questi casi l'autoincrement non ti costringe a portare anche 
l'oggetto sequence e gli eventuali trigger appresso.
 
l'unico vero vantaggio di una sequence è quando c'è una logica dietro la 
sequence (per esempio l'azzeramento in automatico, il salto di valori, 
la cache ecc), e non come mero contatore.
 
 
Ciao

 Ciao
 
Ciao
 
-- 


 e meno male eri quello che sapeva quello che diceva.
 
si peccato che la curval restituisce l'ultimo valore generato dalla sequence per la sessione specifica. Non sono transazionali le chiamate.

 la maggior parte dei clienti
 
E' da poco più di un anno che ci lavoro e confermo. A livello di 
scripting e integrazione di linguaggi esterni mi sembra sia molto 
potente, probabilmente più di MySQL (e Oracle). E come potenza ed 
espressività dell'SQL "proprietario" è molto vicino al PL/SQL.
 
Al CEO / CTO ovviamente non gli puoi sbattere in faccia ragionamente 
tecnici.
Oltre al discorse delle licenze, basterebbe fargli una bella lista di 
aziende blasonate che lo usano...
 
M.


http://blog.aggregatedintelligence.com/2008/12/oracle-sequences-and-concurrency.html
 
 
CurrVal returns the last value generated for a sequence when NextVal was 
called on it. The CurrVal is independent for each session (where a 
session is a distinct connection, as a single database user, to the 
database by an external program). This means that CurrVal will always 
return last value generated for you, regardless of how many times 
NextVal is called by other users on that sequence.
So sequence can be safely used concurrently and you do not have to worry 
about CurrVal returning you some other users current value for the sequence.
 
 
 
E l'esempio di Oracle:
http://docs.oracle.com/cd/B19306_01/server.102/b14200/pseudocolumns002.htm
 
 
 
INSERT INTO orders (order_id, order_date, customer_id)
    VALUES (orders_seq.nextval, TO_DATE(SYSDATE), 106);
 
INSERT INTO order_items (order_id, line_item_id, product_id)
    VALUES (orders_seq.currval, 1, 2359);
 
INSERT INTO order_items (order_id, line_item_id, product_id)
    VALUES (orders_seq.currval, 2, 3290);
 
INSERT INTO order_items (order_id, line_item_id, product_id)
    VALUES (orders_seq.currval, 3, 2381);
 
Ti sembra logico che oracle avrebbe introdotto un metodo come currval 
pericoloso ?
 
 
 

 pericoloso ?
 
voleva fare il genio saputello (a più di 40 anni rotfl) ma ha fatto la figura del fesso.
Tra l'altro un genio saputello dovrebbe almeno saper scrivere in italiano.

 tecnici.
 
Veramente la "T" di CTO sta per "Technology", quindi i ragionamenti tecnici li dovrebbe comprendere. 

 "Solo cio' che piace diventa tradizione" (cit.)
 
Ma smettila :) 
Nel caso di AS/400 si puo` dire che solo cio` che costa vagonate di soldi e ti incastra nei secoli dei secoli diventa tradizione. La mia precedente azienda aveva dei sistemi vecchi di 25 anni basati su AS/400 e DB2, in cui gran parte della logica "server" era scritta in RPG. Un sistema che a livello di manutenzione era semplicemente ridicolo e che li poneva, come concorrenza, almeno 15 anni dietro alle altre aziende.

 ha scritto:

E' quello che si è cercato di dire finora, ma evidentemente c'è gente
che cocciutamente si vuole estinguere come i dinosauri.