Tales from the Machine Room |
Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register
Taanto tempo fa' (ma mica cosi' tanto), $noivendiamolibridisQuola si era fatto fare un bel sito con webnegozio incorporato per... vendere i libri di sQuola (che pensavate?).
Il branco di rimbamba che avevano scritto il sito aveva l'irritante tendenza a rilasciare le versioni per 'testing', correggere gli errori trovati e poi ri-aggiungere gli stessi errori in fase di produzione o (peggio ancora) lasciare la configurazione di produzione come quella di test, con il risultato che poi andare a capire quali "ordini" erano di produzione e quali di test era un bel casino.
Dopo un paio di casini, $$noivendiamolibridisQuola decide di abbandonare il precedente branco di rinco e far sviluppare un sito completamente nuovo da $altrobrancodirinco.
Gia' le cose sono apparse un pelo strane dato che il primo branco ha telefonato domandando a noi (aka: me) il perche' ed il percome della cosa (quajo', quelli dovrebbero essere clienti TUOI, se tu non lo sai il perche') Ma la cosa ha assunto colorazioni tragiche quando abbiamo iniziato a ricevere mail da parte di $altrobranco che domandavano a noi (aka: sempre a me) di interpretare o chiarificare la struttura dati del database dell'applicazione precedente. Hemmm... io ne so niente di questa cosa.
Poi c'e' stato il tormentone della conversione dati dalla struttura precedente a quella nuova. Ora, il database (oracle) risiede sullo stesso server. Abbiamo due schemi, basterebbe fare un bel programmino che legge dallo schema 'vecchio' ed importa i dati nello schema 'nuovo' no? Nooooo!!! Troppo complicato, troppo lungo e soprattutto troppo difficile.
Quello che il $nuovobranco vuole invece e'... un bell'export del database in formato XML! Cosi' poi lo possono importare. Ma c'e' un problema: qualunque cosa questi imbecilli stiano usando per leggere l'XML non riesce a gestire un file superiore ad una certa dimensione, il che significa che l'esportazione deve essere fatta a tranches di massimo 5000 records alla volta. Il che significa che io devo produrre qualche cosa come 180 files che poi loro si elaborano.
Tempo per produrre i files XML: 2 ore. Tempo per comprimere e copiare tutta questa roba sul loro foxxuto server FTP: 1 ora e mezza. Tempo (loro) per processare questa merdaccia e scoprire che hanno un baco nella procedura di importazione ed occorre rifare tutto d'accapo: 2 giorni! Numero di volte la procedura deve essere ripetuta: cosi' tante che mi gira la testa solo a pensarci.
Poi c'e' stata la scoperta che questo coso usa un qualche 'servizio' su un altro server che noi non controlliamo e che se tale 'servizio' per qualsiasi motivo non funziona (tipo se qualcuno decide di spegnerlo perche' pare inutile) si incarta tutto ma senza alcun messaggio di errore riferito a quel famoso servizio che non sta funzionando. Con il risultato che si bestemmia svariate ore a cercare un problema sul server sbagliato.
Comunquesia. Dopo ennemila ore spese a madonnare su questo arnese con giri e rigiri di files di configurazione, impostazioni di memoria minima, permessi di scrittura e robe cosi'. Finalmente giunge il giorno di andare in produzione.
E scopriamo anche che, il sistema nuovo raddoppia l'uso del database senza (apparentemente) aggiungere nulla alle funzionalita' del sito. La cosa raggiunge un livello di isteria quando pare che il sistema sia cosi' lento che si perde letteralmente gli ordini o non processa correttamente i pagamenti.
Il $brancodirintronati decide che "potrebbe esserci qualche problema nell'uso del database" (ma va?). Per verificare inviano una caterva e mezza di query per 'analizzare i dati' (?? adesso li analizzi i dati? che cappero hai fatto nelle settimane prima del rilascio?).
Okkey, prendo la prima query e per poco non mi strozzo con il caffe'.
select * from tabella where id in (select id from tabella2 where id in (select id from tabella3 where descrizione='codice'))
Heeee... 'spetta un momento neh....
select count(id) from tabella3 where descrizione='codice'
1
select id from tabella3 where descrizione='codice'
1
Ok...
select id from tabella2 where id=1;
1
select count(*) from tabella where id=1;
10
Quindi una query con DUE subqueries per estrarre 10 records?
La seconda query e' ancora meglio:
select * from tabella where id in (select id from tabella where codice=1)
Ok, e' il momento di chiedere spiegazioni. Mando una maillina del tipo:
"Stavo guardando queste query e mi sembra che ci sia qualche cosa che non va. La query X e' .... ma non e' la stessa cosa che dire query scritta usando la testa e non il culo? Stessa cosa si applica a..."
Poco dopo mi arriva la risposta:
"si' probabilmente la query ha lo stesso significato, io mi sono limitato a prendere le stesse query che sono nell'applicazione"
Ah... E poi ci si domanda come mai l'uso del database si e' raddoppiato!
"ed in ogni caso il query optimizer probabilmente la riscriverebbe"...
Heeee... 'spetta un momento. Tu assumi che un pezzo di software del quale tu non sai niente (nemmeno se esiste) sia in grado di prendere una query scritta con il didietro e riscriverla come si converrebbe. A parte che le possibilita' che un pezzo di software faccia, senza alcuna richiesta diretta, la cosa piu' logica sono molto poche, ma perche' non utilizzare fin da subito le query giuste? Io forse il perche' lo so, ma per esserne sicuro dovrei fare i raggi al cranio del CL che ha scritto questa ca$$o di applicazione mi sa.
Davide
01/08/2011 08:00
Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.
By Manuel Ravasio posted 01/08/2011 08:18
Forse perchè parlano SQL più o meno come io parlo sanscrito?
O vogliamo indagare nella direzione "non ho idea di cosa sia un DB e di come funzioni" ?
-- Manuel Ravasio
By Anonymous coward posted 01/08/2011 09:00
> select * from tabella where id in (select id from tabella2 where id in (select id from tabella3 where descrizione='codice'))
Io spererei anche che in tabella e tabella2 la colonna "id" non sia chiave primaria. altrimenti 10 record con la stessa chiave non la vedo benissimo.
Anonimo Codardo.
-- Anonymous coward
By FDG posted 01/08/2011 10:15
> select * from tabella where id in (select id from tabella2 where id in (select id from tabella3 where descrizione='codice'))
La mia prima reazione è: ma cos'è 'sta cosa?
Ma soprattutto, gli serve lo '*'? Magari si scopre che dalla tabella2 non leggono una beata fava
By fabiuz posted 01/08/2011 10:18
La radiografia di CL è arrivata:
http://i.dailymail.co.uk/i/pix/2009/04/24/article-1173124-049FADF8000005DC-385_634x488.jpg
:)
-- fabiuz
By Il codardo senza nome posted 01/08/2011 11:30
cit:"Tu assumi che un pezzo di software del quale tu non sai niente (nemmeno se esiste) sia in grado di prendere una query scritta con il didietro e riscriverla come si converrebbe."
... si e alla mezzanotte del 31/12/2011 il sofware diventerà autosenziente e ordinerà ad un esercito di cloni su un pianeta remoto fatto solo di acqua di sterminare il genere umano ...( si lo so li avete visti tutti questi film.. ) ..
@ Il codardo senza nome By Anonymous coward posted 02/08/2011 10:33
cit:"Tu assumi che un pezzo di software del quale tu non sai niente (nemmeno se esiste) sia in grado di prendere una query scritta con il didietro e riscriverla come si converrebbe."
... si e alla mezzanotte del 31/12/2011 il sofware diventerà autosenziente e ordinerà ad un esercito di cloni su un pianeta remoto fatto solo di acqua di sterminare il genere umano ...( si lo so li avete visti tutti questi film.. ) ..
No sbagli candeggio ("citazione ace candeggina") il computer S.i.f.f.r.e.d.i 01 (a causa dei vari porn che si scaricano in continuazione) oridinerà di perpetrare con violenza a chi l'ha creato ciò di cui è stato intossicato e rifare un altro orifizio anale a chi ha scritto quelle boiate così che da far uscire i cattivi pensieri da canali più vicini e rapidi.
Il bastardo con il nickname.
-- Anonymous coward
By Anonymous coward posted 01/08/2011 12:30
Dando un'occhiata superficiale alla documentazione Oracle sul query optimizer, parrebbe che sì, la riscrive, ma come
SELECT tabella1.* FROM tabella AS tabella1, tabella AS tabella2 WHERE tabella2.codice = 1 AND tabella1.id = tabella2.id
che non è esattamente ciò che il tizio di aspetta, suppongo: visto che fa un join per una query idiota. Inoltre, il fatto che usa due volte tabella per ogni query, spiegherebbe in modo semplice il raddoppio dell'utilizzo del DB.
-- Anonymous coward
By guido posted 01/08/2011 13:09
By Anonymous coward posted 01/08/2011 14:56
select * from tabella where id in (select id from tabella where codice=1)
Va beh giù il cappello, questa è classe altro che.
Finisce dritta nel cartello delle bestialità che ho appeso alla mia bacheca in ufficio
-- Anonymous coward
By Riccardo Cagnasso posted 01/08/2011 15:08
La gente che vuole usare SQL e non sa cosa sia il JOIN e' molto piu' di quella che uno normalmente si aspetterebbe.
-- Riccardo Cagnasso
@ Riccardo Cagnasso By ringo posted 01/08/2011 16:37
La gente che vuole usare SQL e non sa cosa sia il JOIN e' molto piu' di quella che uno normalmente si aspetterebbe.
Per estensione: "La gente che vuole usare il computer e non sa che cosa sia è molto più di quella che uno normalmente si aspetterebbe."
SQL e JOIN è un semplice caso particolare della definizione estesa.
-- ringo
@ Riccardo Cagnasso By Programmatore frustrato posted 02/08/2011 00:20
La gente che vuole usare SQL e non sa cosa sia il JOIN e' molto piu' di quella che uno normalmente si aspetterebbe.
Ancora di più è la gente che si definisce un Programmatore quando invece sa a malapena il casino in cui sta andando a ficcarsi.
-- Programmatore frustrato
By Alar posted 01/08/2011 16:17
A me sa di query scritta con interfaccia punta e clicca:
scegli la tabella da leggere
scegli i campi
scegli la chiave e qui un bell'elenco a discesa delle possibili foreign key
-- Alar
By Anonymous coward posted 02/08/2011 00:24
non ho ben capito quale sia il problema con la seconda query
non è mica equivalente a "select * from tabella where codice = 1"
-- Anonymous coward
@ Anonymous coward By Mario posted 02/08/2011 08:55
non ho ben capito quale sia il problema con la seconda query
non è mica equivalente a "select * from tabella where codice = 1"
Avrò letto male o la mia intelligenza sta scendendo mostruosamente, ma SI, è la stessa cosa scritta in maniera giusto un filino più intelligente
-- Mario
@ Mario By Anonymous coward posted 02/08/2011 16:15
Avrò letto male o la mia intelligenza sta scendendo mostruosamente, ma SI, è la stessa cosa scritta in maniera giusto un filino più intelligente
se ho 2 righe del genere la query incriminata le estrae entrambe
id codice
x 1
x 2
poi è ovvio che possa essere una boiata o meno a seconda di COSA contengano le tabelle
-- Anonymous coward
@ Anonymous coward By Alberto posted 02/08/2011 09:01
non ho ben capito quale sia il problema con la seconda query
non è mica equivalente a "select * from tabella where codice = 1"
I risultati sono uguali, il piano di esecuzione (e quindi le performance) no.
I computer fanno quello che gli utenti chiedono, non quello che gli utenti vogliono.
-- Alberto
@ Anonymous coward By Anonymous coward posted 02/08/2011 19:03
non ho ben capito quale sia il problema con la seconda query
non è mica equivalente a "select * from tabella where codice = 1"
Eh giá peccato che fa pure due accessi ripetuti sulla stessa tabella e, anzi, fa un self join sulla tabella! Tanto carino non é...
-- Anonymous coward
By ignazioc posted 02/08/2011 11:42
Ho visto con i miei occhi un db composto da una cinquantina di tabelle create SENZA nessuna relazione e l'autore ed il programmatore "si, lo faccio così tanto poi gestisco tutto via codice..altrimenti se metto le relazioni con la cancellazione dei record è un casino" giuro..l'ho visto con i miei occhi.
-- ignazioc
@ ignazioc By Zanna posted 02/08/2011 23:34
Ho visto con i miei occhi un db composto da una cinquantina di tabelle create SENZA nessuna relazione e l'autore ed il programmatore "si, lo faccio così tanto poi gestisco tutto via codice..altrimenti se metto le relazioni con la cancellazione dei record è un casino" giuro..l'ho visto con i miei occhi.
Io l'ho visto più di una volta e con la stessa motivazione, "gestisco tutto a codice così ho più controllo"... almeno credo che il finale della frase fosse quello perchè dopo "gestisco tutto a codice" le parole successiva erano coperte dalla mia testa che picchiava contro il muro.
-- Zanna
@ Zanna By BPFH posted 03/08/2011 09:25
Non è una cosa così rara da vedere.
Molti gestionali hanno strutture dati di questo tipo, soprattutto se derivati da strutture xBase.
Poi se devi importare i dati sul tuo db che ha le relazioni il programma si incazza perchè importi articoli con categorie che non esistono più... ma naturalmente è colpa del tuo db, non dell'altro scritto con i piedi
Ho visto con i miei occhi un db composto da una cinquantina di tabelle create SENZA nessuna relazione e l'autore ed il programmatore "si, lo faccio così tanto poi gestisco tutto via codice..altrimenti se metto le relazioni con la cancellazione dei record è un casino" giuro..l'ho visto con i miei occhi.
-- BPFH
@ ignazioc By Anonymous coward posted 09/08/2011 15:03
Io lo vedo tutti i giorni quando lavoro sui DB delle maggiorni banche del paese....
Ho visto con i miei occhi un db composto da una cinquantina di tabelle create SENZA nessuna relazione e l'autore ed il programmatore "si, lo faccio così tanto poi gestisco tutto via codice..altrimenti se metto le relazioni con la cancellazione dei record è un casino" giuro..l'ho visto con i miei occhi.
-- Anonymous coward
By Anonymous coward posted 02/08/2011 16:49
L'ottimizzatore riscrive correttamente (più o meno...) se e solo se
1) Non stai usando quello rule based ma quello cost based
2) Hai definito correttamente chiavi e constraint vari
3) Le statistiche del DB sono aggiornate.
Comunque non è una buona scusa per scrivere query a casaccio, ma dal poco che hai scritto l'ntero design del database lascia molto a desiderare, probabilmente. Almeno le variabili di bind le usano o generano n-mila statement identici cambiando solo i valori dei predicati (floodando la cache)? E magari aprendo bei buchi di SQL injection?
E se ha utilizzato select "*" è già da fucilare...
-- Anonymous coward
By camillo posted 03/08/2011 08:55
CREATE TABLE csv ( nriga INT, riga CHAR(1014) );
-- camillo
By Anonymous coward posted 03/08/2011 12:08
Premessa: la query cosi' e' ovviamente scritta con il fondoschiena. E questo fa presagire, query scritte peggio...
Pero' facendo l'avvocato del diavolo, la prima query non e' sbagliata. L'ottimizzatore di query esiste sempre, al massimo puo' funzionare mediocramente o schifosamente...
I piu' precisi lo chiamano query planner. Ovvero un pezzo di software che pianifica come deve essere eseguita la query. Perche' il sql dice cosa vuoi ottenere, ma non specifica come. E quindi c'e' sempre qualcosa che bene o male deve trasformare il cosa in come.
Per farla breve quella query li' e' generalmente equivalente al join. Ovvero tranne casi particolari, ci si aspetta che il planner lo implementi con delle subquery.
La seconda invece e' semplicemente demenziale e la dice lunga su chi ha scritto la query... Mi viene il dubbio che stiano usando qualche framework/software/salcavolo, che scrive automaticamente le query.
-- Anonymous coward
By Anonymous coward posted 05/08/2011 01:01
cit:"Tu assumi che un pezzo di software del quale tu non sai niente (nemmeno se esiste) sia in grado di prendere una query scritta con il didietro e riscriverla come si converrebbe."
Probabilmente è un utente Mac...
--
@ Anonimo molto codardo
-- Anonymous coward
This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.
This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.
This site isn't optimized for vision with any specific browser, nor
it requires special fonts or resolution.
You're free to see it as you wish.