Newsgroup: it.comp.java
Titolo: jdbc e recupero dati da db hsqldb

ciao ha tutti,
ho un problema sul recupero dei dati da un database hsqldb.
Spero di essere nel posto giusto.
Ho una serie di tabelle relazionate tra di loro:
schede ---> sottoschede -----> Attrezzi -----> immagini1
		      !		!
		      !	      	! -----> Criteri ------> immagini2
		      !
		      !------> Difficolta -----> immagini3
 
Praticamente ho fatto una serie di cicli annidati tra di loro
per recuperare, in ordine, prima una scheda alla volta poi le sue 
sottoschede attrezzi, criteri difficoltà e le relative immagini (campo 
byte[] immagine 32x32. Un paio di simboli per immagini1, un paio di 
simboli per immagini2 ed un paio per immagini3, salvato naturalmente un 
record per ogni simbolo). Per facilitarmi il compito ho creato tre view 
tra sottoscheda - Attrezzi - immagini1, sottoscheda - attrezzi - 
immagini2 e sottoscheda - difficolta - immagini3
con jdbc uso preparedstatememt così ogni qualvolta finisce un ciclo, 
sostituisco nella query sottostante l'ID e rilancio l' interrogazione a 
cascata per tutti gli annidamenti.
Man mano che cicla, costruisco un albero di oggetti in memoria con tutti 
i simboli ed alcuni dati che mi servono.
Li elaboro e creo una tabella temporanea che poi dò in pasto a jasper 
report che mi crea il report.
Il collo e proprio quando faccio le query annidate per creare l' albero 
di oggetti (sono quatto annidate) normalmente estraggo una quarantina di 
sottoschede con una media totale di 150-200 simboli e mi ci vogliono una 
20 di secondi ogni volta.
Sicuramente c'è qualcosa da ottimizzare (non sono un mostro in questo)
e, se potete, avrei bisogno di qualche dritta.
Grazie Paolo

 e, se potete, avrei bisogno di qualche dritta.
 
CHe mi tocchi usare un ORM
 


Non e' certo un male utilizzare un framework che ti aiuti a fare proprio quello che ti serve.
Certo se lo utilizzi male potrebbe essere lento quanto la tuo attuale soluzione, ma ci sono buone probabilita' che tu riesca a raggiungere il tuo obiettivo gia' al primo colpo, scoprendo di aver scritto un sacco di codice in meno e di averci guadagnato contemporaneamente in prestazioni, robustezza e semplicita'.
 
-- 
SoulSpirit


Sono d' accordo su quello che dici.
l' unica perplessità che ho è legata alle dimensioni del database.
In fondo sono solo una quindicina di tabelle e quella più grande avrà al 
massimo 800 records (2 tabelle...)
Se devo finire lì forse è meglio escludere Hibernate.....
Provo a documentarmi un po'....
Grazie
Paolo

 Se devo finire lì forse è meglio escludere Hibernate.....
 
Se il progetto fosse ancora piu' semplice opteresti per svilupparlo in QBasic invece che Java?
Non esiste un livello di complessita' minima a partire dal quale si trae beneficio dall'utilizzo di un ORM, anzi: piu' semplice e' il progetto, meno ottimizzazioni sono necessarie, e meno approfondita puo' essere la conoscenza del framework.
Una volta che lo saprai fare ti accorgerai che il setup di un ORM per un nuovo progetto non ti portera' via piu' di 5 minuti.
 
-- 
SoulSpirit

 Se il progetto fosse ancora piu' semplice opteresti per svilupparlo in QBasic invece che Java?
 
QBasic.... mi piacerebbe rinverdire antiche passioni ;)
A dire il vero, se esistesse ancora mi piacerebbe farlo per il C64 
(oops! l' ho conservato assieme a due disk drive, una stampante ed una 
valanga di floppy. Chissà se funzionano ancora, dopo quasi trent'anni).
 
Scherzi a parte, mi sono imbattuto in ormlite..
La cosa interessante è che funziona anche su android.
l' idea è che un tablet è più pratico da usare in palestra invece di un 
pc o un portatile.
Se uso lo stesso db (sqlite) potrei avere una parte dell' applicazione 
già pronta senza dover riscriverla....
Qualcuno l'ha provato?
Paolo

 QBasic invece che Java?
 
Si, se il ritorno sarebbe piu` vantaggioso. Per fare un esempio, un mio 
progetto lo sto portando avanti in Python in quanto a livello di occupazione 
della RAM la controparte Java e` piu` pesante (si, ho gia` fatto tutte le 
possibili ottimizzazioni e no, in Python l'occupazione di RAM rimane meno 
esosa)
 
Enrico

 CHe mi tocchi usare un ORM
 
Inutile, il problema si risolve scrivendo correttamente la query in modo da 
estrarti tutti i dati (o la maggior parte di essi) in una volta sola
 
Enrico

 quello che ti serve.
 
Della serie, usiamo una portaerei con tanto di F-14 e missili terra/aria per 
ammazzare la zanzara che ci infastidisce
 
Enrico

 Sicuramente c'è qualcosa da ottimizzare
 
Hint: "HSQLDB 2.0 supports all the core features and 148 optional
features of *SQL:2008*"
 
(
http://en.wikipedia.org/wiki/HSQLDB
)
 
	Y.

 Sono d' accordo su quello che dici.
 
No gli ORM, per quanto utili in molti campi, non riempiono eventuali 
lacune nella conoscenza del SQL. Tu sembri avere un problema di questo 
tipo, e non di gestione della complessità di un dominio applicativo 
complesso persistito su database relazionale.
 
Devi semplicemente andare di join con SQL.


e che risolvi?
hai un problema di performance in estrazione dati, migri ad un orm e
ti ritrovi pari-pari lo stesso problema di con l'orm. questo perché
anche hibernate risolve le relazioni con query, diciamo così,
annidiate, l'unico vantaggio potrebbe essere il fatto che verrebbero
fatte in modo lazy ma mi sa che non ti serve.
 
 

 complesso persistito su database relazionale.
 
Beccato ;) 
 
 

 Enrico
 
in un colpo solo? e come si fa ?
Ho una tabella (schede) relazionata con un altra (sottoschede)la quale è 
relazionata con altre due(attrezzi e difficoltà).
Di queste due una (attrezzi)è relazionata con un' altra ancora (criteri).
E' una specie di albero ed io stampo  tutte le difficoltà e tutti gli 
attrezzi con i suoi criteri per ogni record di sottoscheda.
Quando faccio un' interrogazione la query ha come clausola where l' id della 
scheda.
vengono estratte le sottoschede di quella scheda e man mano tutto il resto 
ricorsivamente.
Ho forse messo troppe cose assieme ?
Paolog 
 
 

 in un colpo solo? e come si fa ?
 
Anche con una query semplicistica del tipo:
 
SELECT a.dato,
       b.dato,
       c.dato
  FROM a,
       b,
       c
 WHERE 
a.id
 = 
b.id
 
   AND b.altroid = c.altroid;
 
Enrico


giusto...
  e con qualche piccolo adattamento mi migliora le prestazioni.
Per� intanto ho provato questo ormlite.
Devo dire che sono rimasto molto impressionato da questo modo di
interrogare un db.
A parit� di db (con le giuste relazioni)
ho avuto un miglioramento delle prestazioni notevolissimo.
non metto in dubbio che disegnando una query per benino potrei ottenere 
gli stessi risultati, per� una considerazone la voglio fare:
per usare questo pezzo di codice mi devo creare delle classi da mappare 
con il database; in queste classi si possono inoltre implementare dei 
metodi che richiamano tutti i record (sotto forma di liste di classi) 
relazionati.
Quindi salto il passaggio della creazione di un albero di classi in 
memoria con i dati estratti dal db (e gi� questo � un' altro bel vantaggio).
Inoltre se a queste classi di mappaggio ci aggiungo il codice che mi 
serve per manipolare un p� i dati in uscita, in un colpo solo faccio 
quasi tutto.
Mi basta solo fare il ciclo per creare la tabella temporanea da dare in 
pasto a jasperreport :)
Sono sicuro che con un p� di pazienza posso anche elimanare la tabella 
temporanea e se arrivo ad adattare il tutto ad una libreria come 
Openswing, posso lasciare sotto lo strato jdbc in maniera completa ed 
uniformare il tutto.
Questi programmatori sono proprio bravi:
vengono fuori questi pezzi di codice veramente interessanti e ... gratuiti
 
Paolo

 Però intanto ho provato questo ormlite.
 
Che dire, ognuno si fa male come preferisce...
 
Enrico

 Enrico
 
sul serio...!
E' così pericoloso usare un ORM.
Paolog

 E' così pericoloso usare un ORM.
 
E' pericoloso se la motivazione è la mancanza di voglia di imparare il
linguaggio SQL.
 
	Y.

 	Y.
ho capito ;) e mi regolo...............
paolog

 E' così pericoloso usare un ORM.
 
Piu` che pericoloso, e` un inutile appesantimento di codice non richiesto 
(soprattutto nel tuo caso), senza contare che aggiungi uno strato dove non 
serve (per fare un esempio, e` come se per andare al negozio di fronte casa 
prendessi un SUV). Impara l'SQL ed usalo direttamente via JDBC, a meno che 
tu non debba fare cose veramente complesse o rognose, un ORM e` solo un 
inutile orpello in piu` da gestire
 
Enrico


bah, direi sono affermazioni che come minimo vanno contestualizzate. 
claro che per una query non vale la pena, ma già se devi fare operazioni 
di crud su una tabella il guadagno è evidente. figuriamoci poi se si 
parte da una base dati non ancora modellata.
poi francamente non mi risulta affatto l'appesantimento del codice, anzi.
la configurazione iniziale nel jee costa zero, in una applicazione non jee 
un po' di più ma con gli strumenti a disposizione per il kickstart dei 
progetti non è che ci si può fermare perché c'è da fare un po' di 
configurazioni iniziali... il primo progetto si fa l'archetipo e dal 
secondo in poi si parte da quello. 


Visto che ti ho sempre visto parlare di archetype ora (penso parli di 
maven) e appfuse prima, hai mai provato Jboss Forge?

 maven) e appfuse prima, hai mai provato Jboss Forge?
 
no, onestamente no. avevo inizialmente provato spring roo ma non con la 
dovuta convinzione (nel senso che non ci ho mai impostato un progetto che 
andasse in produzione).
però lo valuto.

 poi francamente non mi risulta affatto l'appesantimento del codice, anzi.
 
Per appesantimento di codice intendo il numero di linee da dover scrivere in 
piu`, senza contare le librerie necessarie a poter sfruttare l'ORM. Tutto 
questo senza contare che un progetto complesso lo affronti bene anche senza 
ORM, mentre non e` per nulla detto il contrario
 
Enrico

 ORM, mentre non e` per nulla detto il contrario
 
Ma a me interessano i progetti complessi. E in questi ultimi un ORM può 
fare la differenza soprattutto se non si ha a che fare con database 
legacy mal disegnati.

 bene anche senza ORM, mentre non e` per nulla detto il contrario
 
in estrema sintesi non condivido niente :)
affrontare un progetto complesso, con database relazionale, senza nessuno 
strumento che astrae dalla base dati fisica a mio avviso è un vero e 
proprio suicidio. ovviamente parlo di database relazionali perché per i 
vari nosql la struttura fisica non è proprio visibile e si ragiona solo 
in termini di entity.
quanto alla verbosità a me sembra non ci sia nemmeno paragone fra 
chiamare statement sql select/update/insert/delete e fare la stessa cosa 
con un entity manager.
 

 legacy mal disegnati.
 
Non e` detto, in quanto la base dati potrebbe essere progettata in modo tale 
che risulta molto piu` semplice gestirla a mano
 
Enrico
[1] Prendo in considerazione ORMLite, citato in questo thread, ma presumo 
che anche altri ORM abbiano lo stesso funzionamento
[2] Ok, forse "appesantisce" non e` il termine corretto, ma rende l'idea

 con un entity manager.
 
+1

 che risulta molto piu` semplice gestirla a mano
 
Uno schema di questo tipo è solitamente pieno di cose tipo ridondanze 
inutili, chiavi composte, trucchi vari per relazionarsi con altre 
tabelle (valori negativi che significano tabella A e positivi che 
significano tabella B), eccetera, eccetera.
 
Io queste le chiamo porcherie e rendono quasi impossibile usare un ORM 
al meglio.