Discussione:
CHAIN
(troppo vecchio per rispondere)
frediani
2010-06-16 04:38:28 UTC
Permalink
ho un archivio con chiave univoca composta da CODICE ARTICOLO ed ANNO
facendo una chain su questo archivio impostando il solo codice
articolo esiste un modo per posizionarmi sul primo record (ANNO più
basso) e sull'ultimo record (ANNO più alto)

es.
PIPPO 2006
PIPPO 2007
PIPPO 2008
PIPPO 2009

PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2006
PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2009

il tutto per evitare lo scorrimento del file (SETLL)
Mass8
2010-06-16 06:48:47 UTC
Permalink
Post by frediani
ho un archivio con chiave univoca composta da CODICE ARTICOLO ed ANNO
facendo una chain su questo archivio impostando il solo codice
articolo esiste un modo per posizionarmi sul primo record (ANNO più
basso) e sull'ultimo record (ANNO più alto)
es.
PIPPO 2006
PIPPO 2007
PIPPO 2008
PIPPO 2009
PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2006
PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2009
il tutto per evitare lo scorrimento del file (SETLL)
chiave con 2 campi: articolo e anno e poi chain
Achille Malatrasi
2010-06-16 07:03:09 UTC
Permalink
"frediani" <***@yahoo.it> ha scritto nel messaggio
news:21d88063-4b24-4aae-9514-
... esiste un modo per posizionarmi sul primo record (ANNO più
basso) e sull'ultimo record (ANNO più alto)
SETLL + READ
SETGT + READP
neroni.it
2010-06-16 11:30:49 UTC
Permalink
Post by Achille Malatrasi
news:21d88063-4b24-4aae-9514-
... esiste un modo per posizionarmi sul primo record (ANNO più
basso) e sull'ultimo record (ANNO più alto)
SETLL + READ
SETGT + READP
Più precisamente, definita chiave1 con il primo campo,

Primo:
chiave1 SETLL archivio
chiave1 READE archivio

Ultimo:
chiave1 SETGT archivio
chiave1 READPE archivio

e naturalmente testi il flag di trovato/non trovato.

Con la sola CHAIN trovi solo il primo record del gruppo e servirebbe
descend sulla seconda chiave nella vista logica per trovare l'ultimo.
SETLL e SETGT sono più pesanti di una CHAIN ma la differenza la
vedrebbe solo uno spaccabit dei tempi andati.
E, per far dispetto alla moglie (non usare la CHAIN), nessuno si
taglia le palle (vista logica descend o, peggio, sql uguali a un
rebuild).
Obelix-it
2010-06-16 12:56:04 UTC
Permalink
Post by neroni.it
SETLL e SETGT sono più pesanti di una CHAIN ma
Beh, non molto: in effetti, il sistema fa anche lui una Setll/Reade
quando chiedi una chain(), per cui la differenza e' veramente negligibile...
neroni.it
2010-06-16 16:15:13 UTC
Permalink
Post by Obelix-it
Post by neroni.it
SETLL e SETGT sono più pesanti di una CHAIN ma
Beh, non molto: in effetti, il sistema fa anche lui una Setll/Reade
quando chiedi una chain(), per cui la differenza e' veramente negligibile...
Anch'io l'ho letto ma non credo alla pesantezza anche se mi pare
probabile un comportamento autonomo della chain.
Obelix-it
2010-06-17 06:10:40 UTC
Permalink
Post by neroni.it
Anch'io l'ho letto ma non credo alla pesantezza anche se mi pare
probabile un comportamento autonomo della chain.
No, non, in realta' l Lab hanno spiegato come, in effetti, la Chain
viene trasformata in un Setll (che ricerca una chiave nell'indice) cui
segue uan read (che legge i dati dal RRN identificato prima nel file).
Emanuele Spinelli
2010-06-17 07:29:30 UTC
Permalink
Post by Obelix-it
Post by neroni.it
Anch'io l'ho letto ma non credo alla pesantezza anche se mi pare
probabile un comportamento autonomo della chain.
No, non, in realta' l Lab hanno spiegato come, in effetti, la Chain
viene trasformata in un Setll (che ricerca una chiave nell'indice)
cui segue uan read (che legge i dati dal RRN identificato prima nel
file).
ma e' piu' veloce una chain o una select su un index sql ?
Fabio Terrazzin
2010-06-17 07:40:54 UTC
Permalink
Post by Emanuele Spinelli
Post by Obelix-it
Post by neroni.it
Anch'io l'ho letto ma non credo alla pesantezza anche se mi pare
probabile un comportamento autonomo della chain.
No, non, in realta' l Lab hanno spiegato come, in effetti, la Chain
viene trasformata in un Setll (che ricerca una chiave nell'indice)
cui segue uan read (che legge i dati dal RRN identificato prima nel
file).
ma e' piu' veloce una chain o una select su un index sql ?
dovrebbe essere di gran lunga più veloce la select visto che non
carica nessun dato in memoria.

bye
FT
Fabio Terrazzin
2010-06-17 08:09:51 UTC
Permalink
Post by Fabio Terrazzin
Post by Emanuele Spinelli
Post by Obelix-it
Post by neroni.it
Anch'io l'ho letto ma non credo alla pesantezza anche se mi pare
probabile un comportamento autonomo della chain.
No, non, in realta' l Lab hanno spiegato come, in effetti, la Chain
viene trasformata in un Setll (che ricerca una chiave nell'indice)
cui segue uan read (che legge i dati dal RRN identificato prima nel
file).
ma e' piu' veloce una chain o una select su un index sql ?
dovrebbe essere di gran lunga più veloce la select visto che non
carica nessun dato in memoria.
bye
FT
scusate ho scambiato select per setll... nel post precedente mi
riferivo a quest'ultima.

bye
ft
Obelix-it
2010-06-17 08:00:29 UTC
Permalink
Post by Emanuele Spinelli
ma e' piu' veloce una chain o una select su un index sql ?
Teoricamente, una chain() secca, visto che, perlomeno, non deve passare
per l'ottimizzatore SQL.

Ma IMHO, le differenze sono abbastanza irrilevanti....
Emanuele Spinelli
2010-06-17 09:35:24 UTC
Permalink
Post by Obelix-it
Post by Emanuele Spinelli
ma e' piu' veloce una chain o una select su un index sql ?
Teoricamente, una chain() secca, visto che, perlomeno, non deve
passare per l'ottimizzatore SQL.
Ma IMHO, le differenze sono abbastanza irrilevanti....
sicuramente lo sono, pero' mi sono sempre domandato se in un pgm bacth
con migliaia di operazioni le chain o select facessero la differenza..
forse solo provando...

oggi voglio spaccare il bit in 4 parti :-)


p.s. n.1
l'informatica non puo' essere una scienza esatta in quanto 1+1 = 10
:-)


p.s. n.2
qualcuno forse si ricordera' dei problemi di migrazione delle macchine
linux, ebbene da circa 10 giorni abbiamo terminato e funziona tutto.
ci sono voluti solo 5 mesi in piu' del previsto.
il problema e' stato l'implementazione del GFS che sembra non
funzionasse a dovere... 8:o
Obelix-it
2010-06-17 10:02:05 UTC
Permalink
Post by Emanuele Spinelli
Post by Obelix-it
Ma IMHO, le differenze sono abbastanza irrilevanti....
sicuramente lo sono, pero' mi sono sempre domandato se in un pgm bacth
con migliaia di operazioni le chain o select facessero la differenza..
forse solo provando...
Ti diro', per averlo provato in questi giorni su qualche 100.000
transazioni:

Creare un nuovo gruppo di attivazione e' irrilevante, ma su un 10.000
call si nota eccome : su un programma non banale di stampa fatture, il
tempo triplica... ovvio, devi mettere in coto tutto l'overhead di
chiusura vecchi files/apertura nuovi

Aggiornare 58.000.000 di record su un file di 60.000.000 senza
possiblita' di utilizzo chiave (aggiornamento di un singolo campo, flag
da 1 carattere) :

SQL -> lento
Update RPG -> Buono
Update %Fields() -> Veloce
Suarez
2010-06-17 11:40:11 UTC
Permalink
Post by Obelix-it
SQL -> lento
Update RPG -> Buono
Update %Fields() -> Veloce
intendi Updaate %Field($campo1) vero?
e c'e' credo che e' piu' veloce mentre sql e' il piu' lento, potendo
provare sarebbe simpatico costruirci un indice ho dare al file una
chiave e vedere cosa va' piu' veloce, imvho in questo caso SQL
vincerebbe.

P.S.
domanda maligna, secondo voi e' piu' veloce un UPDAT di rpg II o un
Update di rpg IV?
Obelix-it
2010-06-17 13:01:36 UTC
Permalink
Post by Suarez
SQL -> lento
Update RPG -> Buono
Update %Fields() -> Veloce
intendi Updaate %Field($campo1) vero?
Yes, of course(c)
Post by Suarez
e c'e' credo che e' piu' veloce mentre sql e' il piu' lento, potendo
provare sarebbe simpatico costruirci un indice ho dare al file una
chiave e vedere cosa va' piu' veloce, imvho in questo caso SQL
vincerebbe.
Beh, nel caso in oggetto, dovendo aggiornare 58mln di rek sui 60 mln del
file, la chiave servirebbe poco (anche ammettendo che acceda via chiave,
'skipperebbe' solo il 3%di record, ma la differenza di velocita era
nell'ordine del 50%...
Suarez
2010-06-17 14:28:42 UTC
Permalink
Post by Obelix-it
Beh, nel caso in oggetto, dovendo aggiornare 58mln di rek sui 60 mln del
file, la chiave servirebbe poco (anche ammettendo che acceda via chiave,
'skipperebbe' solo il 3%di record, ma la differenza di velocita era
nell'ordine del 50%...
AFAICR quando vai di sql lui (iddo, o' sistema) si costruisce degli
indici/viste temporanei se non ne trova, attivita che di suo si porta
via un bel po' del carico del nostro server, quindi magara trovando
gia fatto (o forzandogli d'ignorare st'indici temporanei, c'era un
post di Stefano P a riguardo, di qualche anno fa) dovrebbe risparmiare
tempo, e questo lo dico perche' nella mia osservazione quotidiana
(c'ho pure io un pajo di situazioni con decine di milioni di record)
SQL batte "native RPG", che e' il motivo per cui quando posso o debbo
rimettere mano a qualcosa cerco sempre di utilizzare SQL.

Roberto Tempesti
2010-06-16 08:16:29 UTC
Permalink
"frediani" <***@yahoo.it> ha scritto nel messaggio news:21d88063-4b24-4aae-9514-***@x27g2000yqb.googlegroups.com...
ho un archivio con chiave univoca composta da CODICE ARTICOLO ed ANNO
facendo una chain su questo archivio impostando il solo codice
articolo esiste un modo per posizionarmi sul primo record (ANNO più
basso) e sull'ultimo record (ANNO più alto)

es.
PIPPO 2006
PIPPO 2007
PIPPO 2008
PIPPO 2009

PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2006
PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2009

il tutto per evitare lo scorrimento del file (SETLL)

=================

con una chain puoi ottenere solo il primo risultato:

chain (codice_articolo) file;
if %found;
dsply anno;
endif;

vedrai che anno e' uguale a 2006

per fare la seconda cosa dovresti avere una specie di:

anno = *hival;
chain (codice_articolo:anno) file;
if %found;
dsply anno;
endif;


che pur essendo formalmente corretto, risulta comunque in un NOT %FOUND in
quanto anno e' valorizzato a 9999 e la chain trova solo il valore esatto.

Saluti
che
Danilo Cussini
2010-06-16 09:48:28 UTC
Permalink
Post by frediani
ho un archivio con chiave univoca composta da CODICE ARTICOLO ed ANNO
facendo una chain su questo archivio impostando il solo codice
articolo esiste un modo per posizionarmi sul primo record (ANNO più
basso) e sull'ultimo record (ANNO più alto)
es.
PIPPO 2006
PIPPO 2007
PIPPO 2008
PIPPO 2009
PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2006
SELECT X, Y, Z
INTO :x, :y, :z
FROM FREDIANI
WHERE ID_ARTICOLO = 'PIPPO'
ORDER BY ID_ARTICOLO, ANNO
FETCH FIRST ROW ONLY
Post by frediani
PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2009
SELECT X, Y, Z
INTO :x, :y, :z
FROM FREDIANI
WHERE ID_ARTICOLO = 'PIPPO'
ORDER BY ID_ARTICOLO, ANNO DESC
FETCH FIRST ROW ONLY

oppure

SELECT X, Y, Z
INTO :x, :y, :z
FROM FREDIANI
WHERE ID_ARTICOLO = 'PIPPO'
AND ANNO = (SELECT MAX(ANNO) FROM FREDIANI WHERE ID_ARTICOLO =
'PIPPO')
Fabio Terrazzin
2010-06-16 10:16:23 UTC
Permalink
Post by Danilo Cussini
Post by frediani
ho un archivio con chiave univoca composta da CODICE ARTICOLO ed ANNO
facendo una chain su questo archivio impostando il solo codice
articolo esiste un modo per posizionarmi sul primo record (ANNO più
basso) e sull'ultimo record (ANNO più alto)
es.
PIPPO 2006
PIPPO 2007
PIPPO 2008
PIPPO 2009
PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2006
SELECT X, Y, Z
INTO :x, :y, :z
FROM FREDIANI
WHERE ID_ARTICOLO = 'PIPPO'
ORDER BY ID_ARTICOLO, ANNO
FETCH FIRST ROW ONLY
Post by frediani
PIPPO chain ARCHIVIO vorrei posizionarmi su record contenente ANNO
2009
SELECT X, Y, Z
INTO :x, :y, :z
FROM FREDIANI
WHERE ID_ARTICOLO = 'PIPPO'
ORDER BY ID_ARTICOLO, ANNO DESC
FETCH FIRST ROW ONLY
oppure
SELECT X, Y, Z
INTO :x, :y, :z
FROM FREDIANI
WHERE ID_ARTICOLO = 'PIPPO'
AND ANNO = (SELECT MAX(ANNO) FROM FREDIANI WHERE ID_ARTICOLO =
'PIPPO')
in sql la farei così:

exec sql select min(anno), max(anno) into :min_anno, :max_anno
from archivio where articolo='PIPPO'

bye
ft
Loading...