Newsgroup: it.comp.software.database
Titolo: Ricerca case insensitive

Ciao a tutti,
è da un paio di giorni che stò impazzendo con SQL. E' da una vita che
non lo utilizzo e la ruggine è parecchia... Stò cercando di scrivere
una query che mi permetta di estrarre i record che contengono in un
determinato campo la parola che io fornisco come parametro alla query.
Il mio problema è questo. supponiamo che io dimentico attivo il CAPS
LOCK. come posso dire al DBMS di effettuare la ricerca in modo case
insensitive?
Ciao a tutti  e grazie 1000 in anticipo
Marco

 insensitive?
intanto potresti inizare col dire quale è, il DBMS.
ps: rotfl per il CAPS LOCK dimenticato attivo.

 ps: rotfl per il CAPS LOCK dimenticato attivo.
Non sai quanti km ho dovuto fare per dei caps lock premuti per sbaglio
e chissà per quale arcano motivo il DBMS non riconosceva la password o
tornava al cliente un risultato vuoto ad una interrogazione...
Ciao e grazie 1000 in anticipo
Marco

 SQL 2003 per intenderci.
Usa il trucco pi� semplice: ricava l'uppercase del valore inserito e 
ricercalo sul db con la funzione UPPER (o LOWER se preferisci il contrario).
Ciao,
Pablo

 ricercalo sul db con la funzione UPPER (o LOWER se preferisci il contrario).
C'avevo pensato ma speravo ci fosse la possibilità di usare qualcosa
tipo spressioni regolari che sono anch un pò più belline rispetto a
questo barbatrucco.
Grazie 1000 per il suggerimento
ciao Marco

 Grazie 1000 per il suggerimento
Prego, e non scordare mai l'acronimo KISS[1]!
Ovviamente in una qualsiasi delle varianti non offensive ;)
Ciao,
Pablo
[1] 
http://it.wikipedia.org/wiki/KISS_(informatica)

 Ovviamente in una qualsiasi delle varianti non offensive ;)
Mi piace complicarmi la vita per l'eleganza del codice... :D
Però anch eil gruppo musicale non è male!!! :D

 Per� anch eil gruppo musicale non � male!!! :D
Da ragazzo non mi dispiacevano, ora mi fanno solo sentire vecchio! :)
Tra l'altro ho scoperto in questa occasione che non si erano sciolti 
dopo Psycho Circus... (altro che OT, qui siamo sul triplo carpiato)

 dopo Psycho Circus... (altro che OT, qui siamo sul triplo carpiato)
Ascolto solo qualche loro canzone, non sono un loro fan...
[/OT]

 contrario).
Una cosa da tenere a mente: in base al database, potrebbero esserci problemi 
nell'utilizzo degli indici (ovvero non vengono utilizzati per nulla) se vi 
e` di mezzo una clausola UPPER/LOWER
Enrico

 Ovviamente in una qualsiasi delle varianti non offensive ;)
Keep It Simple, "Sciocco"?

 e` di mezzo una clausola UPPER/LOWER
Uhm... brutta cosa.... cmq grazi eper il consiglio vedrò di aggirare
l'ostacolo in qualche modo
Ciao Grazie
Marco

 
Il motore del db, costretto ad applicare la funzione UPPER() a tutti i 
record prima di iniziare ogni ottimizzazione, ringrazia sentitamente.
Nota importante: tranne PostgreSQL, non sono molti i DB che per default 
fanno ricerche case sensitive su campi testo. Con PosrgreSQL una 
particolare sintassi risolve il problema, ma il tuo framework multi db 
avr� qualche problema perch� usciamo dagli standard.

 avr� qualche problema perch� usciamo dagli standard.
Usare un ILIKE invece di un LIKE non dovrebbe creare grossi problemi.
Poi se conosci metodi migliori sempre lieto di imparare.

 Poi se conosci metodi migliori sempre lieto di imparare.
Mi rendo che quello che dir� ti sembrer� inventato per facilitarmi la 
risposta, ma mi � proprio successo: dovendo investire parecchie 
centinaia di migliaia euro su un progetto destinato al maggior numero di 
database, ho fatto escludere PostrgreSQL dai prodotti utilizzabili con 
le prime release (lasciando nel progetto la possibilit� di farlo 
rientrare con un altro budget) perch� prevedeva per default le ricerche 
testuali case sensitive.
Il mio suggerimento � di valutare la possibilit� di non utilizzare 
PostgreSQL.
In subordine tutto dipende da quale sia la tecnologia usata per scrivere 
il framework. Capisci che c'� un abisso, tanto per fare due esempi, tra 
EJB e l'uso diretto di comandi SQL generati dallo stesso programma 
applicativo.
Nel caso in cui si utilizzino tecnologie avanzate (EJB e simili) sei 
nelle mani di altri, e in genere sono mani buone. Se sei pi� fortunato 
di me, che devo pensare a garantire potenzialmente l'efficienza di 
centinaia di tavole per migliaia di utenti per milioni di record, andr� 
tutto bene.
Se il software va direttamente sulle tavole con comandi SQL, occorre 
prevedere nella classe che separa il programma applicativo dalle classi 
di accesso ai dati di terzi (
ADO.NET
, JDBC e simili) tutta una serie di 
strumenti che astraggano il software applicativo dal database di 
destinazione. Purtroppo i gradi di astrazione sono i pi� diversi. Se il 
programmatore applicativo dovr� scrivere SQL vero e proprio, temo che 
occorrer� un parser, il quale potr� contestualizzare la sintassi. In 
questo caso l'uso di comandi come ILIKE diventer� sistematico e non 
controllabile dai programmatori applicativi. All'estremo opposto c'� il 
rischio di scrivere un clone povero di EJB per la parte dati, ma � uno 
scenario troppo drammatico per poterne parlare.

 scenario troppo drammatico per poterne parlare.
Magari se mi definisci "clone povero" ci capiamo meglio... ;)
Ciao,
Pablo

 
Mi riferivo al fatto che si scrivano "in proprio" delle classi per 
ottenere un "object-relational mapping" dopo aver constatato che da solo 
Hibernate non bastava perch� troppo orientato al lato "object" e poco al 
"relational". In effetti mi sono spiegato un po' male, soprattutto 
perch� EJB � molto di pi� rispetto al suo clone.
Spero di non aver definito peggio quello che avevo abbozzato male.

 Spero di non aver definito peggio quello che avevo abbozzato male.
No, ho capito il discorso.
Credo... :)
Ciao,
Paolo

Scusate se non ho più risposto ma con gli esami dell'università sono
in "pausa"con il lavoro...
Piccola premessa. Il mio framework è appunto in Java! mi sono messo a
ascriverlo perchè ne avevo piene le scatole di diventare scemo con JPA
e amici.
Visot che tempo fa avevo lavorato abbastanza intensivamente con Jdbc
mi sono detto "parto da li e vedo di fare qualcosa che mi possa
servire in futuro". soprattutto perchè con JPA ho non pochi problemi a
gestire i plugin, dato che lavoro su applicazioni estensibili.
Il mio framweork permete di comporre tramite drag 'n' drop le query,
salvare il l'oggetto che le descrive in un file xml che contiene anche
la query scritta in SQL99 e ovviamente di eseguirle. L'esecuzione e
l'iterazione sul risultato viene gestita interamente tramite JDBC in
modo del tutto trasparente all'utente. In parole povere mi tiro scemo
io per l'utente ( :D ).
So che pensate che sono un pazzo a fare una cosa del genere ma con JPA
non mi ci trovavo. Probabilmente per poca esperienza in materia ma ho
bisogno di poter espandere le funzionalità dei miei programmi
scrivendo meno codice possibile.
I primi test li farò su di un db del lavoro che sono circa 30 tab con
un qualcosa come 1milione di record complessivi. speriamo di avere
deile buone prestazioni
Ciao Marco

 scrivendo meno codice possibile.
Pazzo no ;) JPA � molto "sunnista" e capisco la tua condivisibile 
esigenza, ma prima hai verificato quello che si trova in giro (link a caso):
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#Java
?
Ci aggiungerei SimpleORM e ActiveObjects.
Ciao,
Pablo

 Ci aggiungerei SimpleORM e ActiveObjects.
Ho provato a guardare un pò di cose prima di prendere questa
decisione. mi sono sparato su TopLink, EclipseLink, OpenJPA. In
passato avevo provato anche Hibernate iBatis e l'implementazione JDO
di Apache ma ho sempre avuto l'impressione di avere le mutande
strette...
Probabilmente è stata la mia ignoranza a portarmi a questa scelta ma
non potevo passare 2 anni a provare ogni nuova libreria per la
persistenza. :|
SimpleORM e ActiveObjects non li ho mai provati magari un'occhio ce lo
butterò più avanti per avere una qualche idea su cosa aggiungere alla
mia lib... :)
Ciao Marco