[PL-SQL] Sfidone del 2 Giugno

[Freeskis]

Ciao a tutti,

Ho da sottoporvi un giocone/sfida per il 2 Giugno, ( o come si dice a lavoro serve per ieri )
io e i ragazzi del team con cui lavoro dobbiamo scrivere un report che prenda i dati da una tabella FACT caricata mensilmente.

il problema sorge qui, i dati vanno caricati dentro un db Oracle da un db DB2 iSeries, ( i due db sono connessi da un DBLink impostato su Oracle ),
il problemaè che i dati all'interno del db DB2 sono caricati senza la minima logica apparente ( roba che manco una scimmia idiota decerebrata riuscirebbe a pensare ad un modo così idiota per piazzare sti dati ).
adesso cerco di spiegare la struttura della tabella il meglio che posso:

la tabella contiene degli importi che si riferiscono a determinati periodi,
la struttura è più o meno questa:

identificativo, anno inizio periodo di riferimento, mese inizio periodo di riferimento, numero di periodi, tipologia di importo, numero righe, importo 1, importo 2, importo 3 ... importo 50.

gli importi sono da 01 a 50 e sono riferiti uno ad ogni mese,

quindi se l'anno di inizio è il 2010 il mese di inizio è l'4 e il numero di periodi è 4, la tabella sarà valorizzata secondo quanto segue:

identificativo, anno inizio periodo di riferimento, mese inizio periodo di riferimento, numero di periodi, tipologia di importo, importo 1, importo 2, importo 3 ... importo 50

340590, 2010, 04, 4, XX, 1, 100, 200, 100, 200, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... fino a 50...
340590, 2010, 04, 4, XC, 1, 100, 200, 100, 200, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... fino a 50...

in questo l'importo uno si riferisce a aprile 2010, il due a maggio 2010 e così via,
quindi il campo 01 sta sempre per il primo mese di competenza indipendentemente quale esso sia

nel caso in cui i periodi di competenza superino i 50 campi la riga scavalla e viene valorizzata la seconda riga, con più o meno questa struttura:

340590, 2010, 04, 4, XD, 1, 100, 200, 100, 200, 150, 150, 150, 150, 150, 150, 150, 150, 150, 150, 150, ... fino a 50...
340590, 2010, 04, 4, XD, 2, 100, 200, 100, 200, 150, 150, 150, 150, 150, 150, 150, 150, 150, 150, 150, ... fino a 50...

ora questa è la premessa, ecco cosa di cui si ha bisogno per caricare la tabella,

numero identificativo, tipologia di importo, importo del mese di competenza, somma dei valori "residui".

spiego brevemente a cosa si riferiscono i due importi, allora se il caricamento viene effettuato il 1 Giugno per l'esempio di cui sopra,
il valore di competenza sarà quello di maggio e quindi è il valore del secondo importo, mentre
il valore residuo comprende la somma di tutti gli importi da quello di maggio ( escluso ) in poi, comprendendo anche quelli di eventuali seconde righe,


potenzialmente nella tabella ci sono più tipologie di importo per ogni identificativo, e per ogni tipologia di importo ci possono essere più righe.

La soluzione io non ce l'ho, o comunque sono a casa quindi non ce l'ho sottomano,
non può essere scritta con SQL standard quindi serve necessariamente il plSQL ...

Spero di essere stato chiaro e che la sfida vi alletti




Ah un ultima cosa,
per lo stesso numero identificativo una tipologia di importo potrebbe iniziare da un mese diverso rispetto al mese di inizio di altre tipologie ma sempre nello stesso anno

[GreatBooks]

Originariamente inviato da Freeskis

Ciao a tutti,

identificativo, anno inizio periodo di riferimento, mese inizio periodo di riferimento, numero di periodi, tipologia di importo, numero righe, importo 1, importo 2, importo 3 ... importo 50.

gli importi sono da 01 a 50 e sono riferiti uno ad ogni mese,

mi complimento con chi ha progettato il DB....ahahahahah!

[Freeskis]

Originariamente inviato da GreatBooks

mi complimento con chi ha progettato il DB....ahahahahah!

purtroppo è il mondo reale, dove i progetti da 3 mesi di sviluppo devono essere consegnati per ieri, e dove non frega un cazzo a nessuno di chi era Codd e chi Boyce basta che le cose funzionino, non importa come.

[khelidan1980]

Originariamente inviato da Freeskis

purtroppo è il mondo reale, dove i progetti da 3 mesi di sviluppo devono essere consegnati per ieri, e dove non frega un cazzo a nessuno di chi era Codd e chi Boyce basta che le cose funzionino, non importa come.

bhe che lo sviluppo orizzontale della tabella sia sbagliato ci si arriva anche senza conoscere Codd e Boyce, e non è questione di funzionare, il fatto è che con un db costruito in questo modo disastroso di ritrovi ad un certo punto ad esser bloccato su futuri sviluppi e devi per forza ristrutturare tutto, detto questo lo letto velocemente ma già ad una prima occhiata per dare una bella sistemata si potrebbe staccare gli importi e strutturarli su una singola tabella,hai una tabella principale con le informazioni di testata e una in cui ci sviluppi quello che penso sia un piano di ammortamento o roba del genere....


P.s: comunque scriverlo in PL/SQL imho dovrebbe esser un vantaggio, ti voglio veder a fare gli update in sql oracle senza l'aiuto del PL/SQL!