La Tabella Del Discontento

Siamo ancora qui' che litighiamo con la foxxutissima applicazione, dopo la tragica scoperta che i dati necessari per la fatturazione sono spariti dal database ed apparentemente dall'applicazione, io sono stato nuovamente chiamato in causa per tamponare la falla intanto che K si inventa un qualche paperocchio per riottenerli.

Per prima cosa mi faccio spiegare da Wendy come dovrebbero saltare fuori sti dati, quindi vado a guardare le informazioni che abbiamo nei log e scrivo un programmello che riempie una tabellina ad uopo per rigenerare tali informazioni.

Sembra fare quello che vogliamo, anche se, con un file di log per 1 giorno di un centinaio di giga ci vuole una giornata intera ad elaborarlo. Io schedulo per elaborare sul giorno precedente (log non-attivo) e risolvo brillantemente (penso io).

Fast-forward al giorno dopo quando K mi compare accanto.

K - Allora, stavo vedendo la funzione di fatturazione.
IO - Ma non hai solo 6 giorni da fare? Ti metti a fare la fatturazione adesso?
K - Eh, DB ha madonnato...
IO - Comunque, io ho creato una nuova tabella che dovrebbe contenere tutti i dati di cui abbiamo bisogno e ci sono gia' dei dati reali dentro.
K - Ah, ma io pensavo invece di modificare le tabelle X, Y e Z per aggiungere le informazioni che vogliamo e...
IO - Bello, ma dato che le informazioni sono gia' nella mia tabella, perche' non te la usi e risolvi cosi'?
K - No ma perche' il codice sarebbe gia' scritto...
IO - Hummm... ieri mi dici che quella parte e' stata eliminata dal sistema ed oggi mi dici che il codice e' gia' scritto?
K - In effetti il codice lo avevamo gia' scritto quando abbiamo deciso di rimuovere la funzione cosi'...
IO - E questo successe quante versioni del database fa'?

Perche' data la tendenza di questa gente ad alterare la struttura dati ogni due per tre non e' che mi fidi molto del suo codice.

In ogni caso mi metto a guardare le tabelle X, Y e Z che questo rintronato vuole modificare. Allora, la mia tabella e' cosi' composta:


indirizzo	char(255)
spam		int(11)
virus		int(11)
clean		int(11)
data		data
direzione	char(1)

Dove 'direzione' puo' essere "o" per Output e "i" per Input. Semplice no? La chiave primaria e' ovviamente indirizzo+data+direzione, perche' un singolo indirizzo puo' esserci solo una volta per data/direzione (i dati sono storicizzati). Mentre le tabelle che lui vuole usare sono cosi' fatte:


indirizzo	char(60)
dominio		char(60)
totale		int(11)
data		data
ora		int(11)
id_cliente	int(11)

Dove le informazioni sono per ora (non per giorno), l'indirizzo e' separato in "indirizzo" e "dominio", invece dei 3 valori spezzati c'e' un solo valore totale ed in piu' compare l'id del cliente (che e' collegato al dominio tra l'altro).

IO - Hummm... ma noi abbiamo bisogno sia delle mail uscenti che di quelle entranti, qui hai solo le uscenti.
K - Si infatti io volevo aggiungere due campi alla tabella: incoming e outgoing ed avere la divisione tra le due.
IO - ...ed il vantaggio tra il modificare questa, modificare la procedura che la crea e la mantiene e modificare le funzioni che la visualizzano (perche' io sono sicuro che ci sono) ed aggiungere una funzione per usare la mia tabella che gia' c'e' ed e' generata sarebbe?
K - Ma perche' la tua tabella ha i dati su diversi record, c'e' un record 'in' ed un record 'out', quindi devo fare due ricerche per avere tutti i dati e questo va a scapito delle prestazioni.

Ora, se state pensando "ma perche' non fa una semplice JOIN", e' perche' non conoscete K. Lui ovviamente non si sporca le mani con qualche cosa di vecchio ed antiquato come SQL. Lui ha questa bellissima libreria Object-Oriented che mette insieme i pezzi e costruisce le "dataview" senza che lui manco veda come e' fatto il database sotto. In effetti ho madonnato parecchio quando cercavo di fargli vedere la struttura dati come e' e non come gliela presenta la sua merda di libreria. Quindi la semplice idea di una "join" e' completamente aliena per lui.

Mi trattengo dall'ammaccarlo e gli dico che guardero' come fare. Mi metto a guardare la procedura che genera la foxxuta tabella che io dovrei modificare. Quella procedura e' chiamata in pipe con il sistema di logging, quindi riceve una linea alla volta, scarta tutto meno la linea con l'indirizzo di posta e memorizza i valori in memoria, al cambio d'ora i dati storicizzati sono scaricati sulla tabella. Ok, non dovrebbe essere troppo complicato modificarla in modo da prendere anche i dati relativi alle mail ENTRANTI oltre che uscenti.

Dopo un paio d'ore ho uno script di test, gli do in pasto uno dei file di log di un paio di giorni fa ed aspetto. Alle 6 di sera decido che me ne vado a casa e domani si vedra'. Il mattino dopo arrivo e scopro che lo script sta ancora lavorando. Ok, fankulo alle prestazioni del sistema.

Mentre sto discutendo la faccenda con K ("discutere" = "spiegare che il tuo sistema non funziona ed usiamo il mio che e' meglio"), arriva DaBoss. Gli spiego il problema.

IO - ...quindi per riempire i dati nella tabella come vuole lui ci si mette una vita, mentre estrarli dalla tabella che dico io e' gia fatto.
DB - Come mai ci mette tanto?
IO - Perche' la procedura che effettua gli inserimenti in quella tabella non e' stata pensata per fare quello e deve fare i salti mortali per trovare i dati giusti. E perche' sono 200 milioni di linee da analizzare al giorno.
DB - (rivolto a K) E perche' non usi la sua di tabella se ha gia' tutti i dati?
K - Perche' nella sua i dati sono su due linee diverse, quindi diventa piu' lento a dare le risposte.
DB - Piu' lento quanto?
K - Hemmm... qualche minuto...
DB - La fatturazione la facciamo una volta al mese, Wendy puo' anche aspettare qualche minuto per avere i dati.
K - Ma la responsivita' del sistema...
DB - (rivolto a K) Fila a modificare il codice!

Ecco a volte amo quest'uomo...

DB - (rivolto a me) A proposito, ho ricevuto l'ennesimo bug-fix da parte dei produttori del CRM e ci sarebbe da provarlo...

Ed altre volte invece...

Davide
27/07/2009 08:00

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

24 messaggi this document does not accept new posts

SQL questo sconosciuto Di Gama postato il 27/07/2009 08:25

Vedo che e' un problema diffuso quello di lasciar fare ad altri quello che sarebbe il proprio lavoro. Anche qui dalle mie parti e' sempre un'impresa riuscire a far eseguire anche la piu' semplice delle estrazioni ad alcune creature che rappresentano la fauna locale perche' abituate a simpatici tools/librerie che "tirano fuori quei dati li'".

Gama -- Tutti abbiamo bisogno di credere in qualcosa... Io credo che mi faro' un'altra birra!

Anonymous coward

Com'è che era? Di Anonymous coward postato il 27/07/2009 09:16

.. la fortuna è cieca, ma Murphy ci vede benissimo?
Però se te lo istighi... -- Anonymous coward

Davide Inglima

@ Anonymous coward Di Davide Inglima postato il 27/07/2009 12:54

> .. la fortuna è cieca, ma Murphy ci vede benissimo?
> Però se te lo istighi...

Com'é che Murphy da semplice ingegnere che enunciò la sua legge sulle cose che vanno storto, é diventato sinonimo di sfiga?

-- http://limacat.blogspot.com

Davide Inglima

Bellissima libreria Object-Oriented Di Davide Inglima postato il 27/07/2009 09:30

Le prime cose a cadere quando se ne va qualcuno sono proprio le bellissime librerie, framework e coding styles.

Ed é proprio per questo che sarebbe bello se la gente la piantasse con l'atteggiamento "When all you have is a nail gun, every problem looks like a messiah" (dove a volte la nailgun la gente se la va a costruire). -- http://limacat.blogspot.com

Lex79_VE

Come iniziare bene la settimana.... Di Lex79_VE postato il 27/07/2009 10:14

[Quote]
DB - (rivolto a K) Fila a modificare il codice!
Ecco a volte amo quest'uomo...

DB - (rivolto a me) A proposito, ho ricevuto l'ennesimo bug-fix da parte dei produttori del CRM e ci sarebbe da provarlo...
Ed altre volte invece...
[/Quote]
Questo mi ha fatto ridere come non mai (forse perchè ti capisco...)
Grazie per farci iniziare sempre bene la settimana big D.

Lex79 -- Lex79_VE

pallini... Di Nik postato il 27/07/2009 10:26

... DB ha i suoi, come dicevi tempo fa... e pure K -- ...

Anonymous coward

CVD Di Anonymous coward postato il 27/07/2009 10:39

JOIN delle tabelle? Ma xchè K non si crea una tabella per tutte le ca$$ate che fà e la elabora? Forse esce qualche cosa di buono!

Per DB = carota e bastone! Non mi dire che non sei contento!!!! -- Anonymous coward

Kurgan

Ma che droga assumono? Di Kurgan postato il 27/07/2009 16:11

K - In effetti il codice lo avevamo gia' scritto quando abbiamo deciso di rimuovere la funzione cosi'...

Non ci posso credere. Il codice e` gia` scritto e poi decidi di rimuovere la funzione... la funziona di FATTURAZIONE? Cioe` hanno COSCIENTEMENTE (e non per mostruosa dimenticanza) deciso di togliere la fatturazione?

Da una persona cosi` mi aspetto che decida coscientemente di rimuoversi il fegato, un giorno o l'altro.

-- Il massimo danno con il minimo sforzo

Riccardo Cagnasso

libreria? Di Riccardo Cagnasso postato il 27/07/2009 16:16

Ma che diavolo di libreria sarebbe la "magnifica libreria"?

Solitamente gli ORM che si rispettino fanno i join e/o li implementano internamente in modo piuttosto efficente, mica fanno query su query. -- Riccardo Cagnasso

@ Riccardo Cagnasso Di Davide Bianchi postato il 27/07/2009 16:24

> Ma che diavolo di libreria sarebbe la "magnifica libreria"?

Non lo so e non lo voglio sapere.
-- Davide Bianchi

Kent Morwath

@ Riccardo Cagnasso Di Kent Morwath postato il 27/07/2009 17:13

> o internamente in modo piuttosto efficente, mica fanno query su query.

Vorrei proprio vederlo un join "efficiente" lato client (rispetto al DB)...

-- Kent Morwath

@ Kent Morwath Di Davide Bianchi postato il 27/07/2009 18:26

> Vorrei proprio vederlo un join "efficiente" lato client (rispetto al DB)...

Se il database non supporta views, qualunque join puo' essere considerata "efficiente" Sicuramente piu' efficiente che ripetere i dati in tutte le tabelle.
-- Davide Bianchi

Kent Morwath

@ Davide Bianchi Di Kent Morwath postato il 27/07/2009 20:26

> > Vorrei proprio vederlo un join "efficiente" lato client (rispetto al DB)...
> Se il database non supporta views, qualunque join puo' essere considerata

Intendo una join non fatta in SQL ma nel codice dell'ORM che prima si scarica i dati delle tabelle in join dal database. -- Kent Morwath

Anonymous coward

@ Kent Morwath Di Anonymous coward postato il 28/07/2009 02:24

> > o internamente in modo piuttosto efficente, mica fanno query su query.
>> Vorrei proprio vederlo un join "efficiente" lato client (rispetto al DB)...

uh? e chi ha detto che deve essere lato client?

Ti faccio un esempio, il Google App Engine Datastore quando usi i metodi per recuperare gli oggetti dal datastore, ti torna un oggetto del cui tipo ora non riporto il nome preciso ma che rappresenta la "query" risultato dei metodi usati. Questo oggetto viene usato dall'utente come un ResultSet iterabile.

Ora, Google App Engine non si appoggia un vero database esterno ma implementa un suo sistema di storage dei dati, detto Big Table (ti consiglio di cercare su youtube "Datastore under hood" perche' e' molto interessante) ma lo stesso principio puo' essere applicato a un normale ORM. Come?
E' facile, quando chiami i metodi per selezionare gli oggetti vai a costruire una query che ritorni sotto forma di un ResultSet iterabile, e quando fai il primo "next" dell'iteratore, valuti la query e recuperi i dati in modo efficente, lasciando tutti i Join al DBRMS che e' tanto bravo ed efficente a valutari.

P.s.
D. non ho potuto loggarmi per un "Internal server error" sulla pagina di login, ma a quest'ora te ne sarai gia' accorto. -- Anonymous coward

@ Anonymous coward Di Davide Bianchi postato il 28/07/2009 07:33

> D. non ho potuto loggarmi per un "Internal server error" sulla pagina di login,
> ma a quest'ora te ne sarai gia' accorto.

Alle 2.25 am ? -- Davide Bianchi

Anonymous coward

data warehouse Di Anonymous coward postato il 28/07/2009 14:32

a volte puo' essere utile evitare molte join sul database transazionale e generare i report su altre basi, magari non normalizzate ma accessibili con query semplici, in modo che perfino un CL potrebbe generarsi i suoi grafici. queste basi sono riempite con dei batch ad intervalli regolari, a seconda delle necessita' dell'organizzazione. ad esempio, questa soluzione potrebbe essere utile se DB volesse dei rapporti per cliente o per data aggiornati quotidianamete -- Anonymous coward

Riccardo Cagnasso

@ Anonymous coward Di Riccardo Cagnasso postato il 28/07/2009 22:41

Direi che e' esattamente per questi propositi che esistono le views.

> a volte puo' essere utile evitare molte join sul database transazionale e generare i report su altre basi, magari non normalizzate ma accessibili con query semplici, in modo che perfino un CL potrebbe generarsi i suoi grafici. queste basi sono riempite con dei batch ad intervalli regolari, a seconda delle necessita' dell'organizzazione. ad esempio, questa soluzione potrebbe essere utile se DB volesse dei rapporti per cliente o per data aggiornati quotidianamete

--
Anonymous coward -- Riccardo Cagnasso

Anonymous coward

@ Riccardo Cagnasso Di Anonymous coward postato il 29/07/2009 10:41

> Direi che e' esattamente per questi propositi che esistono le views.

ni. le views rieseguono le query, i dwh preparano la pappa pronta. in casi di traffico intenso sul db transazionale non vuoi ne' analizzare una base che cambia sotto i tuoi occhi, ne' affaticare un sistema che sta eseguendo le operazioni di update - in gergo figo le CRUD -

p.s. perche' mi mette anonymous coward pure se metto un nome nel campo "Author"? -- Anonymous coward

Riccardo Cagnasso

@ Anonymous coward Di Riccardo Cagnasso postato il 29/07/2009 15:36

>ni. le views rieseguono le query, i dwh preparano la pappa pronta. in casi di traffico intenso sul db transazionale non vuoi ne' analizzare una base che cambia sotto i tuoi occhi, ne' affaticare un sistema che sta eseguendo le operazioni di update

Mmh secondo me e' meglio progettare a modo un db e poi cercare una soluzione a parte a problemi del genere, piuttosto che progettare un db con un sacco di chiavi ridondanti.

Per esempio se sai che vengono richiesti determinati report, non puoi schedularne il batch durante la notte? Oppure non puoi usare un meccaniscmo di replicazione del db per farti una macchina che contiene una replica da usare per questo tipo di report?

>di update - in gergo figo le CRUD -

Veramente CRUD e' un acronimo che sta per Create Read Update Delete che dovrebbero essere le quattro operazioni di base che si prevede di eseguire su un DB e quindi non sono solo operazioni di update. -- Riccardo Cagnasso

Anonymous coward

@ Riccardo Cagnasso Di Anonymous coward postato il 29/07/2009 19:22

>Mmh secondo me e' meglio progettare a modo un db e poi cercare una soluzione a >parte a problemi del genere, piuttosto che progettare un db con un sacco di >chiavi ridondanti.

ed infatti il DWH e' un secondo database che nulla ha a che fare con il transazionale. in un DWH le chiavi ridondanti sono accettabili: sono spesso alla 2NF il tutto per generare velocemente cubi, report etc.

>Per esempio se sai che vengono richiesti determinati report, non puoi >schedularne il batch durante la notte? Oppure non puoi usare un meccaniscmo di >replicazione del db per farti una macchina che contiene una replica da usare >per questo tipo di report?

Dipende dalle necessita', ma spesso queste elaborazioni sono troppo lente, occupano cpu, abbassano la qualita' del servizio del db transazionale ed infine sono piu' difficili da mantenere. Tieni conto che per produrre certi report magari devi coinvolgere piu' database (nel caso della storia di Davide, magari il gestionale ed il db del mail scan) o forse devi mantenere uno storico dello stesso dato etc.. tutte cose che in un db transazionale non sono pratiche per motivi di efficienza e manutenzione. inoltre le esigenze di analisi dei dati per wendy, per DB e per Davide sono diverse, e diverse pure dalle funzionalita' dell'applicazione che riempie il db transazionale con i dati.

>di update - in gergo figo le CRUD -

>Veramente CRUD e' un acronimo che sta per Create Read Update Delete che >dovrebbero essere le quattro operazioni di base che si prevede di eseguire su >un DB e quindi non sono solo operazioni di update.

capisco la puntualizzazione, pensavo non fosse necessario espandere la parola update, cosi' evitiamo che altri lettori capiscano male. una curiosita': per te un soft delete e' una U o una D?
-- Anonymous coward

Riccardo Cagnasso

@ Anonymous coward Di Riccardo Cagnasso postato il 30/07/2009 02:21

>capisco la puntualizzazione, pensavo non fosse necessario espandere la parola update, cosi' evitiamo ?>che altri lettori capiscano male. una curiosita': per te un soft delete e' una U o una D?

Come soft delete indendi marcare un entry come cancellata ( o per non perdere dei dati o per non rovinare l'integrita' referenziale nel caso non sia possibile cancellare on cascade)? Quindi una cancellazione tramite un UPDATE invece che un DELETE?

E' una domanda trabocchetto?

Non credo che ci sia una risposta corretta al 100%, mi sembra una questione di da che punto di vista guardi la cosa. Comunque visto che di solito si indicano con CRUD le funzioni implementate (quando proprio non le applicazioni stesse) lato client, direi che sembra sensato considerarla comunque una DELETE. -- Riccardo Cagnasso

Anonymous coward

@ Riccardo Cagnasso Di Anonymous coward postato il 31/07/2009 14:35

>E' una domanda trabocchetto?

no, una curiosita' mia. ogni tanto ho a che fare con applicazioni fatte cosi', che devo documentare.

> direi che sembra sensato considerarla comunque una DELETE.
sono d'accordo con te, dipende. per me e' la D di uno strato di persistance, che puo' usare un db, un file o uno stenografista velocissimo, ma cio' che implementa e' una delete a livello di "domain layer" - sono un fan di M.Fowler $:-\)$ -
per un dba pero' potrebbe essere una update, metti che debba definire un trigger sul dato, mica ridefinisce il concetto di DELETE in sql, no? -- Anonymous coward

Lo Zeno

@ Anonymous coward Di Lo Zeno postato il 29/07/2009 16:00

> > p.s. perche' mi mette anonymous coward pure se metto un nome nel campo "Author"?

Perché devi fare login, non scrivere il nome nel campo Author. -- 'Computatorem segnem antivirus fecit' Cicero exclamavit; 'neu hodie, Dive maialis, automobilis pergit!'

@ Lo Zeno Di Davide Bianchi postato il 29/07/2009 16:14

> Perché devi fare login, non scrivere il nome nel campo Author.

No, in questo senso ha ragione, e' un bug che ancora non ho avuto il tempo di andare a correggere.
-- Davide Bianchi

24 messaggi this document does not accept new posts

Precedente Successivo

Storie dalla Sala Macchine