Newsgroup: it.comp.software.database
Titolo: null + valore = null

ho una query del tipo:
SELECT c1+c2
Se uno dei 2 campi č NULL viene visualizzato come risultato 'null', mentre
vorrei che 'null' venisse trattato come 0
Es: SELECT null+100 vorrei 100 invece che null
ciao e grazie
Ale
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

dimenticavo uso mysql
ciao


 
NULL non e' un valore. Ogni espressione che contiene NULL vale NULL.
Se vuoi trasformare in zero, usa COALESCE
SELECT COALESCE(c1, 0) + COALESCE(c2, 0);
Questa espressione restituisce sempre un valore numerico.
Ciao
gmax
-- 
 _  _ _  _
(_|| | |(_|><  The Data Charmer
 _|
http://datacharmer.org/

 gmax
-- 


 NULL non e' un valore.
Parole sante. Eppure ho visto innumerevoli testi con scritta la frase
"il valore null...", tanto da diventare ormai un 'errore obbligatorio',
ed incoraggia pure un errato pensiero.
Purtroppo anche i null sono argomento sacrilego, anche se su questo io
sono di solito disposto a fare maggiori digressioni...
imho il discorso null andrebbe ripensato: i null sono estremamente
pratici, ma più che altro l'errore è stato usarla nella 3vl.
ciao

 pratici
Personalmente, nella normalizzazione dei dati, tendo ad evitarli e a
popolare la tabella con un valore fittizio
Enrico

"Enrico Henryx Bianchi":

Già, i valori "speciali"; ti dirò, mi piacciono ancor meno...

 Già, i valori "speciali"; ti dirò, mi piacciono ancor meno...
Il fatto e' che un valore lo gestisci in maniera semplice sempre e
comunque. Il NULL, invece, se non stai attento a come gestirlo, puo'
ritornarti dei risultati imprevedibili
Enrico

"Enrico Henryx Bianchi":

Dunque, innanzitutto super IMHO, ma spero adeguatamente motivato
come vedrete.
Facciamo un piccolo esempio per la ns.discussione:
un'ipotetica tabella misurazioni (font a larghezza fissa).
Tabella secondo SQL-MODEL:
Misurazioni    x    y
-------------------------
Quadrato       100  100
Rettangolo     Null Null  <- sconosciuto
OggettoGrande  999  999   <- conosciuto
Tabella con SPECIAL VALUE:
In questo esempio, si supponga che il valore 999 significhi
"sconosciuto".
Misurazioni    x    y
-------------------------
Quadrato       100  100
Rettangolo     999  999   <- sconosciuto
OggettoGrande  999  999   <- ops!
Se usi gli special value, (1)sei _obbligato_ sia a ricordartene che
a gestirli DA CODICE (a colpi di IF, CASE etc);
inoltre in maniera particolarmente spiazzante (2)alcuni
comandi non funzionano più come ci si aspetterebbe (es. le funzioni
di aggregazione; persino una semplice SUM dà un risultato erroneo);
questo rompe una barcata di regole, riassumibili in una perduta
data independence, in quanto ora fusa col codice che la gestisce.
Faccio inoltre notare quello che secondo me è il maggior problema:
ora il db è pronto a passare _silenziosamente_ dati
errati, dato che sono bypassati definitivamente i meccanismi di
errore per come progettati (propagazione dei null, blocco del
programma). Gli errori sono diventati "invisibili" al db.
Inoltre, gli errori possono avvenire sia in entrata che in uscita:
cosa succede se, come nell'esempio sopra, un utente inserisce proprio
"quel" valore 999; "significa" che non lo sa o "significa" che è
un oggetto grande?
Altri potenziali problemi sono ancora da scoprire, tipo cosa
succede se un giorno vuoi ampliare la scala dei valori: come
ricordarsi di cambiare tutti i posti in cui hai messo gli IF (lo
sai cosa succede se te ne dimentichi, vero?), come fare coi
relativi programmi di cui non hai i sorgenti, cosa
succede alle copie dei dati che contengono ancora i "vecchi" valori
(chi adora Excel fa elaborazioni di dati salvandoseli in
locale e ricaricandoli in seguito: come spiego che nel mentre
l'utente si elaborava i dati, questi hanno... _cambiato_
significato?)
etc...
In definitiva, per me gli special value sono application-managed
data integrity.
Inoltre, posso spesso ravvisarvi errori di modellazione
(semantica debole/confusa: un valore "significa" una cosa, il valore
successivo "significa" un'altra cosa; in questo ci vedo un EAV error)
e/o comportamenti indesiderabili e proni a errori (bundled meaning,
due colonne in una, valori non atomici).
Per come era stato pensato dal Sql-model invece, il supporto è
incorporato nel linguaggio, non nel codice.
Qual è la differenza? L'SQL per quanto criticabile, è standard;
posso cambiare db, dbms, applicazione, un null avrà un comportamento
conosciuto in anticipo, uniforme e inalterato nel tempo (il
comitato Ansi rifiuta le modifiche incompatibili col codice esistente).
Naturalmente sono fatte salve tutte le critiche sulla correttezza
sia dell'SQL sia dell'opportunità dei null nel contesto di un modello
di dati...
ciao

 Rettangolo     999  999   <- sconosciuto
Penso che qui fai un errore di fondo: che il valore fittizio venga
assegnato alla stessa maniera indipendentemente dal contesto. Ad
esempio, e' lapalissiano che nel contesto da te rappresentato il valore
fittizio debba essere 0 (lecito, tra l'altro, in quanto indica
l'effettivo valore in nostro possesso di Rettangolo). Il valore
fittizio, cambia da contesto a contesto. In una tabella Frutti il
valore fittizio della descrizione sara' 'NO_FRUTTO', mentre il valore
fittizio in una tabella di consegne merci la data fittizia di
effettuata consegna potrebbe essere 31/12/9999. C'e' comunque da dire
una cosa: io sono abituato a ragionare a livello di datawarehouse, in
cui un valore e' inserito sempre e comunque in tabella, non foss'altro
per normalizzare i dati
Enrico

 per normalizzare i dati
Cambia poco: non puoi limitare i modi in cui i dati verranno
analizzati. Cosa succede se viene applicata una formula che non
ti aspettavi?