Newsgroup: it.comp.os.linux.sys
Titolo: Re: WTF ??

 Mai le lettere 'WTF???' sono state piu' indicate...
WTF as What.The_Fuck12_33_0_
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)


Cos'é? il pezzo di un codice che tira fuori da un db alcuni dettagli 
delle fatture per una visualizzazione paginata in ordine cronologico 
inverso rispetto all'inserimento nel db?
Direi che di query sql scritte ACDC ne ho viste decisamente di peggiori 
(roba che non sai neanche se stai trattando maiali o coordinate gps).
Almeno qui i nomi delle colonne sono leggibili e, incapsulamento a parte 
delle 3 query per la paginazione e dall'abuso degli 'as', rimane ancora 
una semplice select da una sola tabella.
Luca


Stramerita di finire sul daily wtf, anche se di solito prediligono le 
query kilometriche piuttosto che gioielli di concisione come questa


Una curiosità (se possibile)
Che motore di database è ?

 Mai le lettere 'WTF???' sono state piu' indicate...
naaa... è "semplice" paginazione (select * from (FUFFA + rownum) where 
:1<rownum<:2) + un modo molto "particolare" di evitare colonne con nomi 
uguali? ma questa query "fa parte" di query diverse? (cheneso', è un pezzo 
da mettere in join con altra fuffa?)
-- 
By ZeD

 row_ ) where rownum_<= :1 and rownum_>  :2
Umh.... con tutti quegli alias dotati di indici puzza di query generata 
da un ORM e predisposta per paginare i risultati. Ne ho viste di 
moooolto peggio, specie quando si seleziona/filtra su più tabelle correlate.
Fantastico che qualcuno abbia deciso di riciclarla così com'era...
-- 
r--r--r--

 Mai le lettere 'WTF???' sono state piu' indicate...
Sembrano le query che tira fuori Hibernate...
-- 
Massimo Bacilieri AKA Crononauta

Crononauta wrote:

Mi sfugge quale sia la semplificazione nel chiamare un campo delivery3_33_0_ 
invece che delivery_note_number
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

invece che delivery_note_number
Che rendi incompatibili (e quindi in caso di cambiamenti te ne accorgi) le
query del front-end versione 3.33.0 con quelle di ogni altra versione.
La presenza di codici come "8_33_0_" mi fa pensare pero' che ci sia dietro
qualche spiegazione ingegnosa come solo un CL puo' ideare.
(Esiste la sigla CDBA?)
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 qualche spiegazione ingegnosa come solo un CL puo' ideare.
No, sono proprio query auto-generate da (N)Hibernate. Il perchč siano 
cosě dovreste scoprirlo dalla documentazione... io mi accontento di 
leggerle cosě :-(
Mauro

 'ySQL'.
MySQL Enabled Relational Database Application?


ROTFL :-D


 Appunto, una _semplice_ select da _una_ tabella...
Quelle query in quel modo (lasciamo perdere l'abuso degli alias) si 
scrivono per due motivi:
1) si è imbecilli
2) si cerca di ottimizzare la query per restituire i risultati più 
velocemente.
La 1) è veramente rara a verificarsi, perchè comunque sottintende un pò 
di intelligenza.
Se la query gira per 15 minuti allora i problemi possono essere 3:
1) i dati nel DB sono veramente tanti
2) il DB gira su una macchina obsoleta
3) il DB è strutturato come il culo e non ha indici.

 qualche spiegazione ingegnosa come solo un CL puo' ideare.
No, come hanno già suggerito quelle sono query generate
automaticamente da hibernate o altro ORM similare.
bye!

 Sembrano le query che tira fuori Hibernate...
stavo per scriverlo io ;^)
bye!

manca un'indice...
Raccomando: "The Art of SQL" :-)



wrote:



Vorrei osservare che questo sposta solamente la domanda :-D


 manca un'indice...
Quel tipo di query si usa quando vuoi utilizzare lo pseudo-campo rownum 
(che, a quanto ne so, esiste solo su Oracle dove trova una sua utilità. 
Altrove è inutile).
L'utilizzo di rownum per alcune cose, (ad esempio per simulare il LIMIT/
OFFSET di myscul o postgres) prevede proprio annidamenti di quel tipo.
La query esterna è solo per il limit/offset, ovvero per estrarre i record 
desiderati.
La query intermedia serve solo per aggiungere i vari rownum al dataset.
La query interna serve per estrarre il dataset ordinato.
Semplicemente, su oracle, certe cose si devono fare in questo modo.
Anche io anni fa (>10), quando mi approcciai ad Oracle, rimasi basito di 
certi tipi di arzigogoli (all'epoca ero abituato solo a myscul).
Mi pare una chiavica di query solo per la scelta dei nomi, per il resto è 
assolutamente decente.
Se ci mette 15 minuti il dataset è enorme o non ci sono indici o la 
macchina non è adatta a quel carico di lavoro (e ci sono molte altre query 
pesanti che girano contemporaneamente) (leggasi, non prendertela con chi 
ha scritto la query ma col DBA).
L'unica altra opzione è che i segnaposto :1  e :2 indichino un range 
estremamente ampio di dati e il tempo che ci mette a passarli al lato 
applicativo è soprattutto tempo di trasferimento dati sul socket.

 Vorrei osservare che questo sposta solamente la domanda :-D
Un ORM gestisce persistenza e interrogazione di grafi di oggetti. Per 
persisterli su db è spesso necessario creare una struttura più complessa 
di quella di partenza: una relazione molti-a-molti necessiterà di una 
tabella ponte, una classe di oggetti che eredita da un'altra sarà 
spalmata su due tabelle dove la prima contiene i campi della classe base 
e la seconda contiene solo quelli che estendono la base in relazione 
uno-a-uno con la precedente, ecc...
In conseguenza di ciò quando viene generato l'sql che estrae i dati 
richiesti la probabilità di dover fare join multipli carpiati, 
sottoquery a N livelli e altre mostruosità è molto elevata e per evitare 
all'origine di dover gestire ambiguità nei nomi dei campi la via più 
breve è assegnare sempre e comunque un alias ad ogni campo usato e poi 
lavorare con questi invece del nome originale.
-- 
r--r--r--

 Vorrei osservare che questo sposta solamente la domanda :-D
Point.
;)
bye!


Premesso che spesso vedo db senza chiavi primarie (prima ancora che 
senza indici, che è peggio), foreign key, ecc., che spesso vedo fare 
prodotti cartesiani invece delle join (i vari dbms ci mettono del loro 
per cercare di ottimizzare, ma quasi sempre non possono che fare dei bei 
sequential scan), bisogna notare che incapsulando query in sottoquery 
(come ha fatto chi ha scritto questa) si perdono indici.
Seconda cosa, il filtro sul numero di riga così implementato obbliga il 
server prima a costruire tutte le righe (se sono veramente tanti record, 
con tanti definito come >100k, ci vuole il suo tempo), poi ripassarle 
tutte per verificare su ciascuna se il numero è compreso tra i limiti.
Anche l'operazione di ordinamento nella query più interna rompe 
qualsiasi possibile indicizzazione ci potesse essere prima.
Quasi tutti i dbms con cui ho lavorato hanno un costrutto "limit" e 
"offset" nel liguaggio che permette di dire immediatamente quali righe 
si vuole ottenere in modo più efficente.
Terza ed ultima cosa, sold_order_line_details è una tabella o una view? :-)
Luca

lavorare con questi invece del nome originale.
Sono d'accordo. Quello che mi torna meno è di scrivere
	delivery3_33_0_
anziche'
	aliasPippo.deliverynumber
a meno che 3_33_0_ non codifichi il livello di nesting (ma 33 non me
lo spiegherei comunque).
3_33_0 mi fa pensare a un maj/min/rev number, ecco.


 si vuole ottenere in modo più efficente.
Non oracle :->
(volendo in quella query si possono raggruppare le due query più esterne 
ottenendo lo stesso risultato, ma sono sicuro che oracle si comporterebbe 
allo stesso modo, altrimenti non sarebbe il migliore sul mercato)


Dubito che quel codice sia stato scritto da un essere umano,
probabilmente è stato scritto da un automa artificiale.
Comunque a parte i nomi usati,la parola chiave 'as' non necessaria in 
oracle, la select al livello 0 non necessaria (ma non inficia le 
prestazioni), un indice da inmpostare su 
sold_order_line_details.id
è una normale query

 Sembrano le query che tira fuori Hibernate...
Quoto.