Newsgroup: it.comp.lang.delphi
Titolo: Una condizione where

in una select Sql voglio esprimere una condizione where, tramite parametro o 
altro, che esprima un valore o un range di valori o qualsiasi valore.
Potrei usare l'espressione ' where IN (...)' e questo soddisfa la mia 
esigenza, salvo che nel caso di 'qualsiasi/tutti' i valori. In questo caso 
dovrei elencare tutti i valori possibili, oppure evitare del tutto di 
esprimere la condizione; ma vorrei usare sempre la stessa query se 
possibile. E' possibile ? 
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 possibile. E' possibile ?
 
Ad una sintassi SQL con la IN non puoi assegnarci parametri per un semplice 
motivo: quanti ne prevedi?
 
Quindi per fare quello che chiedi l'unico sistema è costruirla a runtime 
stando molto attento alla SQL Injection.
 
Comunque sia, elencare tutti i valori possibili in una IN non è affatto una 
buona soluzione...
 
HTH
 
 

 possibile. E' possibile ? 
 
Purtroppo no. In SQL i parametri possono solo essere degli scalari.
Dati complessi come liste o tabelle non si possono usare.
L'unico modo e' di generare il testo sql al volo ogni volta.
 
ciao
Giacomo

 esigenza, salvo che nel caso di 'qualsiasi/tutti' i valori. 
 
Non devi. Stai sbagliando qualcosa nel design della tua applicazione.

 Non devi. Stai sbagliando qualcosa nel design della tua applicazione.
 
Scusa, se non sai cosa deve fare la sua applicazione, come fai a sostenere 
che sta sbagliando qualcosa?
 
 

 che sta sbagliando qualcosa?
 
Perche` non bisogna necessariamente conoscere cosa deve fare un'applicazione, per capire che l'approccio alla risoluzione di un problema e` sbagliato. Quando si ha un po' di esperienza nello sviluppo del software, si sa quali sono gli antipattern in cui gli sviluppatori (inesperti) normalmente incappano. Concatenare SQL, per esempio, e` uno di questi. Se hai bisogno di ficcare in uno statement SQL troppi valori costanti (e, se variabili, puoi farlo solo per concatenazione), stai necessariamente sbagliando qualcosa. Hai probabilmente bisogno di eseguire una JOIN su db o approcciare il problema da un'altra direzione.

 problema da un'altra direzione.
 
Se un cliente ti chiede una stampa e vuole poter selezionare uno, n oppure 
tutti i clienti, tu come la fai? Gli dici che non puoi farla perché è un 
antipattern?
 
 

 antipattern?
 
Rileggi quello che ho scritto, perche` non hai capito una mazza. Non ho mai affermato che Stark non deve fare quello che vuole fare. Ho detto che deve farlo nel modo giusto.

"4ndre4"  ha scritto nel messaggio 
news:ba38c991-0406-4b1f...@googlegroups.com...
Non devi. Stai sbagliando qualcosa nel design della tua applicazione.
...
Ma si tratta di una funzionalità molto semplice. Praticamente una situazione 
riassuntiva di vari valori annuali che l'utente potrebbe volere complessivi 
per tutti i conti o per specifici conti. Potrei semplicemente farlo con due 
select diverse, l'una che non contiene la condizione di estrazione dei conti 
e l'altra che contiene una condizione sui conti (in genere l'interesse è su 
un singolo conto o su un numero limitato che rappresenta una certa classe di 
conti). Volevo verificare se c'era qualche soluzione per risolverla con 
un'unica select.
Potrei fare una lista di tutti i conti e usare l'espressione IN(...), ma i 
conti potrebbero essere un centinaio, se non di più.. 


 conti potrebbero essere un centinaio, se non di più..
 
La IN, come gia` detto, non va bene. Devi pensare ad una soluzione migliore, probabilmente riorganizzando i tuoi dati. Purtroppo, se la struttura dati non e` progettata con criterio, ti trovi poi nei pasticci.

> Perche` non bisogna necessariamente conoscere cosa deve fare un'applicazione, per capire che l'approccio alla risoluzione di un problema e` sbagliato. Quando si ha un po' di esperienza nello sviluppo del software, si sa quali sono gli antipattern in cui gli sviluppatori (inesperti) normalmente incappano. Concatenare SQL, per esempio, e` uno di questi. Se hai bisogno di ficcare in uno statement SQL troppi valori costanti (e, se variabili, puoi farlo solo per concatenazione), stai necessariamente sbagliando qualcosa. Hai probabilmente bisogno di eseguire una JOIN su db o approcciare il problema da un'altra direzione.
 
Dato che anche a me è successa una cosa simile mi farebbe piacere conoscere "l'altra direzione" e farla nel modo giusto.
Nel mio caso dando la possibilità all'utente di selezionare uno o più campi di una tabella con varie possibilità di filtri ho definito una funzione che costruisce dinamicamente la query SQL. Lavorando su una tabella singola non ho capito quando parli di JOIN su DB.
 
Ciao da Enrico c/o Anthelios

 Rileggi quello che ho scritto, perche` non hai capito una mazza.
 
L'ho riletto e non ho capito una mazza lo stesso :-(
 
 

 L'ho riletto e non ho capito una mazza lo stesso :-(
 
Allora e` un problema tuo, e non ci si puo` fare proprio niente.
 

 Nel mio caso dando la possibilità all'utente di selezionare uno o più campi di una tabella con varie possibilità di filtri ho definito una funzione che costruisce dinamicamente la query SQL.
 
Costruire le query dinamicamente e` una delle cose piu` pericolose che si possa fare nella scrittura del software, perche` si presta bene a varia "injection". Non so cosa tu stia facendo nello specifico, per cui non posso consigliarti sulla direzione precisa da prendere. Dovrei vedere, ad esempio, come sono strutturati i tuoi dati. Posso solo dirti di stare attento a non incappare nei piu` comuni antipattern. Se ti trovi, ad esempio, nella necessita` di dover inserire troppi valori in una "IN" di una query, probabilmente quella sorgente dati puo` benissimo essere una tabella, per cui la IN altro non e` che la JOIN con un'altra tabella che fa da fonte dati.

> Costruire le query dinamicamente e` una delle cose piu` pericolose che si possa fare nella scrittura del software, perche` si presta bene a varia "injection". Non so cosa tu stia facendo nello specifico, per cui non posso consigliarti sulla direzione precisa da prendere. Dovrei vedere, ad esempio, come sono strutturati i tuoi dati. Posso solo dirti di stare attento a non incappare nei piu` comuni antipattern. Se ti trovi, ad esempio, nella necessita` di dover inserire troppi valori in una "IN" di una query, probabilmente quella sorgente dati puo` benissimo essere una tabella, per cui la IN altro non e` che la JOIN con un'altra tabella che fa da fonte dati.
 
Nello specifico credo di averlo detto prima, praticamente io faccio vedere all'utente una list-box con tutti i campi di una tabella ( es. clienti ), a questo punto l'utente seleziona il campo provincia e mette il valore "MI", poi seleziona il campo tipo struttura e mette "T" e così via. Al termine io gli visualizzo tramite la query costruita i clienti interessati ai criteri precedentemente effettuati. I dati su cui eseguo la query sono sempre ricavati da una tabella soltanto senza JOIN e non uso MAI le IN. A parte che non ho la più pallida idea di cosa sono gli antipattern a questo punto mi sapresti dire quale potrebbe essere la soluzione migliore ?
 
Ciao e grazie da Enrico Giudici c/o Anthelios.

On Thursday, 19 May 2016 10:30:07 UTC+1, 
enrico....@gmail.com
  wrote:
 
[...]da una tabella soltanto senza JOIN e non uso MAI le IN. A parte che non ho la più pallida idea di cosa sono gli antipattern a questo punto mi sapresti dire quale potrebbe essere la soluzione migliore ?
 
Non ho capito perche` vuoi da me la "soluzione migliore" al TUO problema. Io sto rispondendo al quesito posto da Stark...
 
 

> Non ho capito perche` vuoi da me la "soluzione migliore" al TUO problema. Io sto rispondendo al quesito posto da Stark...
 
Se non ricordo male hai risposto a Shark di pensare a una soluzione migliore, quale ? Se non ho capito male il problema di Shark è lo stesso del mio.
 
Poi testualmente dici "Non so cosa tu stia facendo nello specifico, per cui non posso consigliarti sulla direzione precisa da prendere. Dovrei vedere, ad esempio, come sono strutturati i tuoi dati." a questo punto mi sembra di averti chiarito esaustivamente la mia situazione e da come parli sembra che una volta capito la situazione potevi dire la tua sull'alternativa migliore.
 
Io non voglio da te la soluzione ma visto che da come parli hai in mente alternative migliori, queste mi piacerebbe che tu le condividessi con me e con Shark. Anche secondo me la costruzione sql delle query è pericolosa ma dopo vari post non mi sembra che hai ( nello specifico di Shark e mio ) specificato alternative.
 
Ciao da Enrico Giudici c/o Anthelios
 

E questa soluzione ? (esempio):
'Select * from MyQuery where MyQuery.Id IN (' + aStringList.CommaText+')';


 Io non voglio da te la soluzione ma visto che da come parli hai in mente alternative migliori
 
Non ho in mente ALCUNA alternativa. Sto solo dando dei caveat sui piu` conosciuti antipattern.

 'Select * from MyQuery where MyQuery.Id IN (' + aStringList.CommaText+')';
 
Ma a che ti serve fare una cosa del genere? Tu devi selezionare i dati in base ad un criterio specifico. Marca in qualche modo i record da processare e poi selezionali, piuttosto che porre tutti gli id in una IN.
 

 A parte che non ho la più pallida idea di cosa sono gli antipattern a questo punto mi sapresti dire quale potrebbe essere la soluzione migliore ?
 
Per una descrizione piu' lunga puoi cercare su wikipedia, ma in
breve gli antipattern sono delle "brutte abitudini", modi di fare
le cose che sembrano migliori per una serie di ragioni (e' il modo piu'
rapido, ...) ma che alla fine portano piu' problemi di quelli che
dovrebbero risolvere.
 
ciao
Giacomo

 
 
ti ringrazio della spiegazione 4ndre4 è troppo avanti per me.


 Non ho in mente ALCUNA alternativa. Sto solo dando dei caveat sui piu` conosciuti antipattern.
 
ok, a questo punto credo che io e Stark abbiamo capito cosa non fare. Per cui caro Stark per le nostre realtà dobbiamo seguire le indicazioni di 4ndre4 e riuscire a trovare sistemi diversi da quelli utilizzati.
 
Ciao da Giudici Enrico c/o Anthelios

 ti ringrazio della spiegazione 4ndre4 è troppo avanti per me.
 
Non darti per vinto, prendila come un'occasione per andare a
studiare delle cose che non sai e migliorarti sempre :-)
 
ciao
Giacomo

 Ma a che ti serve fare una cosa del genere?
 
Secondo me lui ha una serie di valori dello stesso tipo e li deve estrarre da una tabella, credo.
 
 Tu devi selezionare i dati in base ad un criterio specifico. Marca in qualche modo i record da processare e poi selezionali, piuttosto che porre tutti gli id in una IN.
 
Potresti per cortesia essere più chiaro dato che a priori hai sempre detto che non conosci cosa sta facendo nello specifico e non conosci come sono strutturati i dati.
 
Ciao e grazie da Giudici Enrico c/o Anthelios

 
 
Sante parole.
 
Ciao e grazie 1000 da Giudici Enrico c/o Anthelios

 ok, a questo punto credo che io e Stark abbiamo capito cosa non fare. Per cui caro Stark per le nostre realtà dobbiamo seguire le indicazioni di 4ndre4 e riuscire a trovare sistemi diversi da quelli utilizzati.
 
Ragazzi, saper programmare significa saper organizzare i propri dati in maniera tale da evitare i piu` comuni antipattern. Se non sapete farlo, la colpa non e` mica mia, eh?

 Potresti per cortesia essere più chiaro
 
Piu` chiaro di cosi` si muore.

 utilizzando i parametri invece che modificare direttamente la query:
 
La cosa dei parametri la puoi fare anche con le IN... Ma sempre la sintassi 
SQL a runtime ti devi generare...
 
:Citta1, :Citta2, ... CittaN
 
E quando nel mio primo post ho scritto "stando molto attento alla SQL Injection" 
pensavo proprio all'utilizzo dei parametri che ti tolgono diversi problemi.
 
Ma da qui al dire che le IN in una sintassi SQL non devono essere utilizzate 
ce ne corre.
 
David
 
 

 ce ne corre.
 
Dipende dal contesto in cui ti trovi. Se sviluppi una web application la
sql injection e' un problema fondamentale che devi assolutamente
affrontare. Se sei in un contesto di C/S su una LAN puoi chiudere un occhio.
 
Per citare un altro frequentatore del niusgruppo... "l'importante e'
farlo consapevolmente" :-)
 
Poi dipende da come ottieni i dati: Se hai una griglia e vuoi dare
all'utente le possibilita' di lavorare su un subset che puo' selezionare
lui con ctrl+click sulla griglia stessa, la lista degli ID la compili
prendendo il campo ID dalla griglia, il rischio di sql injection e'
molto molto basso. Questo ti consente di adottare la tecnica "sconsigliata"
senza troppo i scrupoli.
Una tecnica alternativa piu' solida potrebbe essere fare delle INSERT in 
una tabella temporanea di "righe selezionate" e poi operare in join con
questa tabella. Di sicuro la Sql injection in questo caso non puoi
averla. Pero' hai N insert in piu' sul DB... e' il solito dilemma
sicurezza vs velocita' :-)
 
ciao
Giacomo

 "injection".
 
E perché, vale la pena di ricordarlo, il piccolo Bobby Tables potrebbe essere
in agguato: 
https://xkcd.com/327/
 
 
Enrico

 una tabella temporanea di "righe selezionate" e poi operare in join 
 
A seconda dei casi (in c/s!) uso l'una o l'altra.
Ovviamente (ma non per tutti) devi prevedere COME MINIMO dei sistemi solidi per ripulire la tabella per evitare che resti "sporca" di selezioni obsolete, sia  la gestione di selezioni da utenti/postazioni/sessioni diverse.
 
In ambito web si deve tener conto del numero di utenti...
 
 
A.