Newsgroup: it.comp.java
Titolo: Query temporale su DB

Salve... mi serve un suggerimento/consiglio: devo realizzare un db (usero' 
decisamente hsqldb) per memorizzare informazioni, che devono essere 
registrate in relazione ad un preciso giorno. Nell'ottica futura di fare 
ricerche temporali (del tipo "tutto quello che e' successo a novembre 
2006"), conviene fare una colonna di tipo Date (o anche Timestamp?) e poi 
fare una query opportuna (come?) oppure fare delle colonne giorno/mese/anno 
e complicare la logica dell'applicazione per verificare che i tre campi 
siano consistenti fra di loro (evitare il 31 novembre, tanto per dire)?
Grazie
CarMas

 fare una query opportuna (come?) oppure fare delle colonne giorno/mese/anno 
Timestamp se ti interessano anche le informazioni di orario, altrimenti 
Date. Lascerei decisamente perdere la storia delle tre colonne.
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.html

 Date. Lascerei decisamente perdere la storia delle tre colonne.
Ok grazie. Non mi interessano gli orari, solo il giorno... quindi 
(correggimi se sbaglio) creo la colonna di tipo Date, che se non ho letto 
male la documentazione dovrebbe essere il solito long (millisecondi passati 
dalla mezzanotte del 1/1/1970), poi quando devo fare la query mi creo due 
Date che rappresentano gli estremi temporali, ne "estraggo" il relativo long 
e semplicemente imposto la clausola where richiedendo che il campo data sia 
compreso fra quei due valori.
Sono sulla strada giusta?
Saluti
CarMas

 Sono sulla strada giusta?
Uhmm, meglio utilizzare i PreparedStatement. Crei la query con una 
stringa tipo:
PreparedStatement pstmt = con.prepareStatement(""select * from myTable 
where date1 > ? and date2 < ?"");
e poi imposti i valori dei parametri cosě:
pstmt.setDate(...)
Per dettagli guarda qui:
http://java.sun.com/j2se/1.5.0/docs/api/java/sql/PreparedStatement.html


 where date1 > ? and date2 < ?"");
Sorry, i doppi "quotation mark" sono dovuti a un errore di copy and 
paste :-P


Attenzione ad estrarre i long dalle Date.
In questo modo sei costretto ad ottenere anche un'informazione sull'orario,
e fare paragoni tra date come tu intendi (giorno mese anno) e millisecondi
(compresi ora minuto secondo ecc..) potresti avere delle brutte sorprese
quando tenti di fare query del tipo Da... A...


 
http://csvtosql.sourceforge.net
Troverai sollievo alle vane fantasie se compirai ogni atto della tua vita
come se fosse l'ultimo. -- Marco Aurelio, "Colloqui con se stesso"

 pstmt.setDate(...)
Che era quello che dicevo io ^^
Solo che io sbagliavo perche' facevo riferimento ai long invece di usare 
direttamente Date. Naturalmente quando scriviamo Date stiamo parlando di 
java.sql.Date, giusto?
Ho visto che il costruttore con i 3 int (anno, mese, giorno) e' deprecato, 
per cui credo che usero' il metodo statico valueOf("yyyy-mm-gg") per 
ottenere le due date da usare come estremi. Poi mi permetto di correggere il 
tuo statement, nella mia forma finale dovrebbe risultare cosi':
conn.prepareStatement("select * from myTable where date > ? and date < ?");
setDate(1, data_iniziale)
setDate(2, data_finale)
Saluti
CarMas

 quando tenti di fare query del tipo Da... A...
Si grazie. Ho abbandonato l'idea dei long e sono tornato sui Date da usare 
direttamente nel preparedStatement.
Saluti
CarMas

 decisamente hsqldb
Personalmente ti consiglio di andarci cauto nella scelta di HSQLDB. In
un lavoro che ho fatto, in cui dovevo eseguire connessioni concorrenti e
contemporanee al database (5 thread aventi una propria connessione che
leggevano, scrivevano e cancellavano le stesse tabelle), mi sono
ritrovato con parecchie rogne a causa del fatto che l'unico livello di
isolamento delle transazioni supportato e` di tipo READ UNCOMMITTED
(ovvero, anche se non faccio il commit dalla connessione a, la
connessione b vede le modifiche da me fatte). Questo ovviamente senza
contare alcune idiosincrasie di HSQLDB (e.g. il fatto che di default non
viene eseguito il controllo sulla dimensione dei campi, allo stesso
codice di errore sono associati due messaggi differenti, e che in caso
di chiusura non corretta scriva male il file di log). Personalmente, se
sei deciso ad usare un database scritto in Java, ti consiglierei di
provare Apache Derby (e` praticamente Cloudscape, rilasciato da IBM come
open source e immesso da Sun dentro Java 6 come Java DB). Se invece vuoi
interamente cambiare tecnologia, ti consiglio Firebird (e` un fork open
source di Borland Interbase) o PostgreSQL
Enrico
P.S. ovviamente tutto cio` che ti ho detto e` basato sulle esperienze
che ho fatto di persona. Cio` include anche il fatto che ho usato HSQLDB
in un contesto non a lui congegnale, e che molto probabilmente in altri
ambiti riesce a tirare fuori tutto il suo potenziale al meglio

 Date che rappresentano gli estremi temporali
Piu` che due classi Date, ti consiglio due classi Calendar, La
classe Date e` deprecata a favore della classe Calendar, e quest'ultima
ha dei metodi setter e getter che ti permettono di ritornare tutto cio`
che ti serve per impostare la data
Enrico
P.S. l'oggetto Date non e` totalmente deprecato in quanto viene usato
ancora in molti ambiti (e.g. estende l'oggetto Date del package
java.sql, che viene utilizzato sia nel preparedStatement che nel ritorno
di una data estratta dalla query)

 connessione b vede le modifiche da me fatte). 
Hai visto H2?
http://www.h2database.com/


 siano consistenti fra di loro (evitare il 31 novembre, tanto per dire)?
Non scherzare :-)

 
http://www.h2database.com/
Si, ma non ne ho mai letto nulla/non l'ho mai provato
Enrico
P.S. comunque, basta scavare un po' per trovare un mondo interessante di
motori RDBMS scritti esclusivamente in Java (mi ricordo che una volta ne
ho provato uno che sembrava la risposta in Java a SQLite. Si chiama
SimplySQL)

 
http://www.h2database.com/
Mi sono appena andato a rileggere le funzionalita`, e devo dire che si
prefigge abbastanza interessante. Rimango pero` lo stesso perplesso
sulla sua scelta. Apache Derby proviene da un progetto ben definito e
con un supporto commerciale. Inoltre, il suo inserimento nella libreria
standard di Java 6 promette molto di piu` di quanto ci si aspetti da un
progetto simile. Infine, per farla breve, devo dire che i miei dubbi
provengono anche dal fatto che gia` una volta ci sono rimasto scottato,
e non mi piacerebbe ripetere l'esperienza (non a breve, almeno)
Enrico

 e non mi piacerebbe ripetere l'esperienza (non a breve, almeno)
Sinceramente l'ho appena scoperto anche io..
Beh l'autore del progetto è lo stesso di HSQLDB (H2 sta proprio per 
Hipersonic 2), immagino abbia fatto tesoro delle esperienze precedenti. 
Non fosse altro che perché la persona merita mi riservo di darci uno 
sguardo approfondito.
pole

 Beh l'autore del progetto è lo stesso di HSQLDB 
Se e` lo stesso autore di HSQLDB allora e` da sfanculare (non il
progetto, ma l'autore stesso). Ah, una cosa che mi ha lasciato
perplesso, e` che per i dati crea un solo file. E se ho piu` di 2GB di
dati e il file system non supporta file di quelle dimensioni?
Enrico