Newsgroup: it.comp.lang.visual-basic
Titolo: Ma allora c'è il Null

Dal libro Guida a SQL di Guidi-Dorbolò è lecito, in una Insert Into, passare
come valore di un campo il valore Null.
Ho verificato su access e funziona, anche su un campo che non accetta
lunghezza zero.
Non so con altri database, magari poi provo anche msde, e mi aspetto che
funzioni pure li.
Ma mi viene un dubbio; ho sempre letto, mi hanno sempre detto, che i
database "seri" non prevedono il valore Null, e allora mi chiedo: possibile
che un linguaggio universale come sql preveda il valore null solo per
access?
Greg

 database "seri" non prevedono il valore Null
Personalmente i valori Null li sego in partenza (e non saluterei chi li ha
inventati), ma quella sopra è tutto meno che la verità.

 wrote in message
news:b93fic$f6too$1...@ID-129608.news.dfncis.de...


 lunghezza zero.
Lunghezza zero si riferisce alle stringe, il null è la proprietà
"Richiesto".
Ciao

 Server. L'utilità di tale valore poi... è tutta da discutere.
Dici?
Sono curioso: ma tu e Lupo (vedi altra risposta) cosa mettete nei campi
VARCHAR vuoti? spero non uno spazio...
Ciao
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 VARCHAR vuoti? spero non uno spazio...
Stringa nulla/vuota, ovvero "", ovviamente ben diverso da Null

 Server. L'utilità di tale valore poi... è tutta da discutere.
Una informazione che non hai come la codifichi in un db?
E un campo di join che non punta a niente?
Ciao
Alberto

 ha scritto nel messaggio
news:b955sk$feirj$1...@ID-174464.news.dfncis.de...

Ovviamente *in VB*... vero su Access e SQL Server, probabilmente anche
Oracle che non ho sottomano, non ci scommetterei per tutti i database, pero'
Tanto per dire, apri una tabella DBase con DAO, e provi a fare
UPDATE ... SET Campo = ''
quello che viene salvato e' NULL, tanto e' vero che con il recordset con
l'analoga
SELECT WHERE Campo = ''
e' vuoto, mentre con IS NULL nessuno problema.
Comunque anche qui rientriamo nei gusti personali, per quanto mi riguarda se
un campo testo non deve contenere niente preferisco che ci sia dentro
*niente* (vi seguo gia' di piu' sui campi numerici dove, se non ha
significati particolari, preferisco anch'io uno zero piuttosto che NULL);
basarsi su stringa vuota puo' avere qualche comodita' in fase di lettura, ma
ti comporta comunque del lavoro in piu' altrove: in crezione tabella spesso
devi esplicitare che le colonne devono accettare stringa vuota (es. Access),
in fase di inserimento devi sempre menzionare tutti i campi,
indipendentemente da cosa vuoi salvare, in fase di modifica della struttura
del DB devi lanciare un UPDATE a tappeto per impostare il valore su tutti i
record ecc.


 record ecc.
Abbiamo già dato ;-)
http://makeashorterlink.com/?I20732274
http://makeashorterlink.com/?V22712274

 ha scritto nel messaggio
news:b93foo$e5s62$1...@ID-174464.news.dfncis.de...

Confermo entrambe le asserzioni... :-)))
I database "seri" ce li hanno, eccome, i null.
Il problema è che quelli meno seri (come Access), pur avendo i null,
non li sanno gestire bene, ecco l'inghippo.
Di fatto, i null sono più una palla al piede che un aiuto per lo
sviluppatore.
--
Er Roscio.

 li ha inventati), ma quella sopra è tutto meno che la verità.
Ciao a tutti,
Io penso che i NULL siano più o meno utili a seconda di
come uno "interpreta" il valore NULL.
Esempio: Lupo interpreta( se non ho capito male ) il NULL come
"valore vuoto", mentre io - per esempio - lo interpreto come *assenza*
di un valore, cioè valore NULLO  ovvero assente.
In questo contesto, il valore NULL ha grande importanza, poiché ti
permette di inserire "a posteriori" determinati valori che magari
non possono essere impostati in prima battuta.
Quindi per me un NULL equivale ad un "N/D"( Non Disponibile ) non
come ad uno zero.
My 2c,
Andrea

*The DeerBear* ha scritto:

No, no! Lupo sa bene che il Null informatico significa, sinteticamente,
"dato non inserito", ma, Lupo stesso, _decide_ di intenderlo come:
"una merdaccia fantozziana inventata da uno sclerotico di nome Bill (o,
scusate se non mi sono documentato, di chi per esso) che ha la presunzione
di rappresentare il "Nulla". Lui (l'iniziale è dovuta al punto che precede,
non certo a uan supervalutazione), nella sua mente sconvolta, può certo
farlo, io, nella mia mente assolutamente carente, no."
Il nulla non esiste e in una scatola (campo) io (nè altri) non posso mettere
il nulla. Allora, più realisticamente, preferisco evitare problemi
sintattici (per esempio nel recupero dei campi a Null) e sego in partenza i
Null, ovvero ci metto un valore convenzionale (discutibile fine che si
vuole) che è, tipicamente "" per i campi testo e 0 per i campi numerici.
Certo, e non discuto, non saprò mai se un campo è 0 o non indicato, ma com'è
possibile, nella realtà, rappresentare il nulla? Un prezzo a 0 per me
significa 0/non indicato, una descrizione a "" per me significa nessun
carattere/non indicata. Strano? Non credo proprio, perchè se dico a
chicchessia "cos'è il nulla per te?" quello prima chiama il 112, 113 e 118 e
poi, dopo che mi vede, tranquillo, in camicia di forza, mi urla "ma tu sei
pazzo scatenato!". E ride.

 farlo, io, nella mia mente assolutamente carente, no."
Naaah... Bill stavolta non c'entra...
Sarà perché ho qualche annetto informatico più di lui,
ma il Null viene dal modello relazionale di Chen e Codd
(pubblicato nel '74). Bill a quei tempi andava ancora alle medie...
Concettualemente non sarebbe malaccio rappresentare
la differenza tra "valere 0" e "dato non disponibile",
ma se poi tutto il resto del contesto non si adegua
per gestire il tutto, devi aggiungere tanto di quel codice
per ovviare agli errori, che ti passa il piacere e ti vien voglia
di tornare ai file sequenziali !... :-)))
--
Er Roscio.

 camicia di forza, mi urla "ma tu sei pazzo scatenato!". E ride.
Ovvio, ma tu non devi chiedere all'utente cos'è il nulla per lui,
tu devi solo dargli il modo di distinguere tra un valore "corretto",
uno "disponibile ma pari al vuoto" ed uno indisponibile.
Non mi sembra nulla di trascendentale, in fin dei conti.
Ovvio, nel tuo codice un intero di valore NULL lo rappresenterai con
zero o col primo valore non corretto che puoi confrontare( per esempio
se è una data la puoi porre a -1 e confrontare quello ).
Nella mia visione, totalmente discutibile, delle applicazioni database,
una cosa è come rappresenti il dato nel DB, un'altra è come lo rappresenti
nel
programma ed un'altra ancora è come lo rappresenti per l'utente.
Sono io complicato?
Andrea

 pazzo scatenato!". E ride.
  Ma "il nulla" con l'informatica non ha attinenza!
 
--------------------------------
Inviato via 
http://usenet.libero.it

 Sono io complicato?
No. Viva la differenza!
Sarò io pazzo?

 Sarò io pazzo?
Non penso proprio
Andrea

 Come la rappresenti?
0, zerooooooooooooooooooo!
Dimmi, ditemi: Che senso ha la data=0 (a parte, per chi crede, la nascita di
Cristo o altre convenzioni calendaristiche, ci mettiamo una velina o una
Pamela, qual è la differenza)? Nessuna, dico io. Che senso ha una data a
Null? Nessuna, dico io e voi. Dov'è la differenza fra me e voi?

 Dov'è la differenza fra me e voi?
Che noi siamo + belli :-P
Andrea

 Oppure N/D ^_^
Entro un attimo nel thread per buttare lì la mia.
Il Null è uno strumento potentissimo.
Che poi uno decida di non usarlo, dipende da come disegna il db.
Tuttavia, esistono casi in cui è necessario usarlo, e va saputo usare.
Prendiamo un caso di un campo numerico. Butto lì, la tensione esistente fra
i due poli di un circuito.
A priori, non è possibile sapere quanto varrà. E neppure definire un valore
'non valido' da sfruttare per memorizzare il dato 'non ancora misurato'.
Supponiamo però di accettare di cablare nel codice una 'porcheria', ossia di
definire che fra i due poli non potrà mai esserci più di un migliaio di Volt
di differenza, per cui usiamo -999999999 come indicativo di 'non ancora
misurato'.
Siccome per memorizzare un valore analogico saremo portati ad utilizzare
campi in virgola mobile, soprattutto se vogliamo buona precisione, ecco che
ci autofreghiamo in partenza.
La famosa storiella dell'IF variabile=123.45 che non funziona, vale anche
per i dbms, non è una cosa di VB.
Quindi, il nostro -999999999 potrebbe essere memorizzato
come -999999998.99999999999999, ed ecco che una eventuale clausola where
fallirebbe.
Ovviamente, possiamo cercare di prevenire questa cosa, usando colonne con
formati numerici a virgola fissa, verificando che il valore da noi scelto
come pseudo-null non cada in questo caso di arrotondamento, ecc....
Però, a questo punto ci troviamo di fronte a problematiche ben più ostiche e
indebuggabili rispetto all'uso di un semplice null.
Per cui, personalmente uso i null, e, dopo averlo fatto, mi ritrovo, quando
devo metter mano ad un vecchio db, con molti più vantaggi che svantaggi
(basti pensare alla comodità del join che viene 'interrotto' dalla presenza
del null, mentre con valori di default, soprattutto se uguali fra due
tabelle, potremmo avere join falsi).
Ciao
Alberto


  Ma naturalmente!
Ciao


Albe V°,
Taglio tutto, ma complimenti per il post, un'efficace combinazione di
sintesi, teoria e pratica.
Questo me lo sono salvato ;-)
-- 
ciao, hal


Leggo da un testo su SQL:
"NOT NULL non deve essere utilizzato a sproposito.
Non si deve mai utilizzare il valore NULL, per rappresentare qualcosa di
diverso da "valore sconosciuto", poichè i calcoli sui valori NULL possono
essere complicati, soprattutto se utilizzati con le funzioni aggregate.
Nota: allo stesso tempo va sottolineato che per alcuni prodotti tra cui DB2,
per ogni valore inserito in una colonna che non sia stata definita come NOT
NULL, SQL deve registrare un segno in più (invisibile). Tale segno indica a
SQL se il valore è NULL oppure no. In altre parole, una colonna NOT NULL
occupa meno spazio di un'identica colonna che accetta valori NULL:"
giuseppeD

 giuseppeD
Ciao
Andrea

 2) Non vedo come questo modifichi quanto detto da me o Alberto.
Inserire nel discorso un passaggio di Rick van der Lans, e non dichiararlo
come mio, mi sembrava contribuire al thread.
Due i punti ineressanti, secondo me, presenti:
1-  "poichč i calcoli sui valori NULL possono essere complicati, soprattutto
se utilizzati con le funzioni aggregate."
Funzioni aggregate tipo:
COUNT , MIN , MAX , ecc.
2- "per ogni valore inserito in una colonna che non sia stata definita come
NOT
NULL, SQL deve registrare un segno in piů (invisibile). Tale segno indica a
SQL se il valore č NULL oppure no. In altre parole, una colonna NOT NULL
occupa meno spazio di un'identica colonna che accetta valori NULL:"
indicazione che reputo importante.
Salve
giuseppeD

 accetta valori NULL:" indicazione che reputo importante.
Interessante.
Non ha niente a che vedere con il thread, ma almeno so una cosa nuova.
Ciao
Alberto