Newsgroup: it.comp.software.database
Titolo: i NULL e la teoria relazionale

Saluti.
Sto leggendo il libro "SQL and Relational Theory" di Date.
In questo libro, come in molte altre risorse in rete, si elencano i 
problemi con i NULL, e si invita a non usarli.
Molti di questi problemi derivano, a quanto ho capito, dalla complessità 
di una logica a 3 valori, e dalle idiosincrasie (alcune davvero notevoli) 
di SQL, nella sua implementazione dei NULL.
Tuttavia l'"informazione mancante" va comunque espressa; tanto che lo 
stesso Codd ha introdotto i NULL nella teoria relazionale [1] [2].
Date fa questo esempio:
COALESCE (PNO, 'nil') AS PNO.
L'esempio riguarda una LEFT OUTER JOIN, ma fa anche un esempio 
utilizzando UNION e sotto query.
Io mi chiedo: che senso ha?
Mi ricorda i problemi che si hanno con il C, quando una funzione deve 
restituire una condizione speciale, e lo fa utilizzando un valore 
"speciale" del tipo usato.
Ad esempio -1, per il descrittore associato ad una risorsa, gestita 
tramite il tipo `int`.
I NULL vanno davvero evitati, anche nel caso in cui, ad esempio, voglia 
fare una OUTER JOIN, e processare il risultato in un programma esterno?
Io ci tengo molto alla teoria, ma ragionare senza i NULL mi risulta 
abbastanza difficile.
[1] 
http://en.wikipedia.org/wiki/Null_(SQL)
[2] Date nel suo libro, dice che invece i NULL non fanno parte della
    teoria relazionale; come stanno le cose?
Grazie   Manlio

 
quoto l'uso di 'in genere' e '99%', ma imho null e' una informazione a 
tutti gli effetti.
tanto per, tabella utenti con tracciamento del last login.
utente appena creato:
lastlogin = null
e' corretto e previsto, perche' l'utente non ha mai avuto accesso.
e ragionando sugli utenti, l'informazione lastlogin = null ha un suo 
significato e una sua utilita'.
al posto del null si potrebbe mettere un flag del tipo 
'haLoggatoAlmenoUnaVolta', impostare la data in 'lastLogin' a un valore 
farlocco o altro, ma imho il null e' la soluzione piu' semplice e robusta.
dipende dai casi: null ovunque e' cattiva progettazione, non usare null 
'perche' di no' certe volte complica la vita.
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--



ciao,
la materia è parecchio interessante e a suo tempo ci avevo sbattuto la 
testa anche io. Purtroppo adesso non ho tempo più troppo da dedicarci, ma 
ricordo che il problema non era solo quello individuato da Date ma era 
più vasto e riguardava l'implementazione della WHERE nello standard ANSI 
SQL. Se hai tempo/voglia leggi anche quì:
http://www.firstsql.com/iexist2.htm
ciao
M.

 
I NULL invece escono abbastanza facilmente, ad esempio con una LEFT JOIN.
Questo tipo di query sono sconsigliate, proprio perchè progettate per 
restituire NULL.
Date afferma che le OUTER JOIN sono una specie di UNION, con NULL usato 
come padding, per rendere le tabelle conformi.
Io a volte ho bisogno proprio di questo tipo di unione, ed usare NULL 
come "padding" invece di un valore sentinella (come fa Date nell'esempio 
che ho postato) mi sembra più ragionevole.
Ciao  Manlio

 I NULL invece escono abbastanza facilmente, ad esempio con una LEFT JOIN.
Un conto sono i NULL restituiti da una query, un altro sono i valori
NULL nelle tabelle.
Personalmente evito il più possibile i campi NULL nelle tabelle.
Diverso il discorso dei risultati delle query (uso comunque molto
COALESCE) e i parametri delle funzioni, specialmente quelle di
ricerca.
Li evito il più possibile, non significa che non li usi mai.
L'esempio con il last login fatto sopra è uno di quei casi dove la
cosa va scelta con discrezione e valutando l'applicazione nel suo
complesso. Genericamente preferisco loggare i login a parte (e se è
un'applicazione web inserisco anche altre info, come l'ip, per
reperirle più rapidamente che non dai log di apache).
Per una data di pubblicazione di un prodotto, un articolo o altro, su
postgresql uso -infinity e infinity, ma su sql è comodo l'utilizzo di
NULL.
Tuttavia contro i NULL:
- in molti casi rendono il codice un po' più complesso
- le applicazioni devono fare più controlli
- i campi NULL hanno comportamenti diversi a seconda del motore db
utilizzato o anche solo a seconda delle impostazioni di
un'installazione
- a volte fanno risparmiare codice, ma rischia di essere un boomerang
Ciao,
Lucazeo

 [...]
Ciao  Manlio

 abbastanza difficile.
Concordo. I NULL servono proprio per rappresentare un valore diverso
da qualsiasi altro valore del dominio di una colonna, usare un valore
del dominio a mio parere e' proprio concettualmente sbagliato. Io
sento addirittura la mancanza di questa feature nei linguaggi
tradizionali come il C! :)
Oltre tutto se usi il '-1' per indicare "nessun riferimento" quando
hai un'integrita' refernziale su un'altra tabella sei costretto
ad aggiungere un record fittizio (-1, 'nessun valore', ...) nella
tabella corrispondente
Quello che e' davvero "autolesionista" nei NULL e' la logica a 3
valori,
se ci fosse una logica normale a 2 valori, in cui NULL=NULL e x=NULL
puo' essere o vero o falso (eliminando la stupida condizione "is
null")
penso si avrebbe il meglio dei due mondi, una teoria coerente e una
implementazione piu' pratica di quella attuale.
Per lo meno gran parte degli errori che fanno i principianti in SQL
sparirebbero perche' il risultato atteso sarebbe piu' spesso simile
a quello ottenuto! :)
ciao
Giacomo

Manlio Perillo <manlio_p...@SPAMlibero.it> wrote in
news:kTg8n.128818$
9f6.1...@twister1.libero.it
: 

non puntavo a trovare LA soluzione al caso specifico.
volevo solo mostrare che e' possibile che il NULL sia un valore valido e 
accettabile, oltre che significativo...
situazione semplice, caso particolare, quello che volete, ma imho il null 
non e' necessariamente un valore senza senso dovuto alla pigrizia di chi fa 
inserimento dati.


 inserimento dati.
Altro esempio, se devo memorizzare una tabella con una funzione
matematica, per me ha decisamente senso una cosa del genere:
n    1/n
-------------
1    1
2    0.5
3    0.33
0    NULL
-1   -1
-2   -0.5
-3   -0.33
se dovessi usare un valore sentinella del dominio farei fatica
a deciderne uno che vada bene per n = 0...
ciao
Giacomo

 
Esempio infelice, perchè lo standard per i numeri a virgola mobile già 
prevede valori speciali come Inf e NaN.
Su come si propaga NaN, ci sarebbe tanto da dire, comunque.
Ciao  Manlio

 prevede valori speciali come Inf e NaN.
Si, vero, ho scelto proprio male! :)
Ma questo mi fa dire un'altra cosa: se son stati definiti quei due
valori "sentinella" e' proprio per la stessa ragione del NULL di
dover indicare qualcosa di "fuori dal dominio".
ciao
Giacomo

 [...]
Ciao  Manlio

 a deciderne uno che vada bene per n = 0...
Molto semplicemente quella tabella non avrà una riga con n='0', il 
concetto di NULL è espresso dal fatto che il dato non è presente.

 teoria relazionale; come stanno le cose?
Il modello relazionale e` nato senza i NULL, ed ha cosi` proseguito
per circa 10 anni; e` solo a questo punto, coincidente coi primi
successi commerciali, che Codd ha deciso di "estendere" il modello
relazionale con qualcosa di digeribile dai moltissimi nuovi utenti.
Niente di impossibile che cio` sia avvenuto su pressioni esterne
originate dai primi successi commerciali...
Date ha cercato di restaurare il tutto riproponendo il modello
relazionale "originale" senza null; aggiunge pero' un sistema basato
sui magic values che secondo me e` ancora peggiore... ma almeno
dice chiaramente che si tratta di una proposta incompleta.
I NULL sono uno dei piu' grandi errori fatti nel settore, destinato
purtroppo a durare molti decenni per il fatto che e` diventato uno
standard (assieme all'SQL); si puo' solo sperare che l'SQL affondi
sotto l'ingordigia dei produttori che continuano a spararci dentro
ogni porcheria dettata dalla moda del momento (e` gia' sulla buona
strada).
bye 

 concetto di NULL è espresso dal fatto che il dato non è presente.
Pero' questo approccio ti obbliga a spezzare una relazione in N
relazioni, un base a quanti attributi potrebbero essere nullabili.
Secondo me a livello pratico rimane piu' vantaggioso indicare
la non esistenza con il NULL.
ciao
Giacomo

 
L'SQL non credo affonderà, perchè non ci sono alternative valide.
Piuttosto, la gente comincerà a migrare verso database "non SQL" (che poi 
non si capisce se sono semplicemente "non SQL" o "non relazionali").
Ciao  Manlio

 relazionali").
Vedasi infatti il movimento NoSQL (
http://nosql-databases.org/
)
nato di recente, che mira a fare una bella rivoluzione.
Secondo la definizione ivi riportata, per "non sql" si intendono
"non relazionali" (scritto per primo, tanto per chiarire
chi e` l'avversario).
E' interessante notare che lo slogan contro il modello relazionale
bersaglia proprio il suo presunto punto debole, l'SQL, strategia
che ha un'allarmante possibilita` di successo...
Jim Gray preconizzo' il sentimento di insoddisfazione populista
da lontano, nel suo mitico "A Call to Arms":
http://queue.acm.org/detail.cfm?id=1059805
una critica [*] a 360� che all'epoca sembro' una sparata, ma
che il cosiddetto Cloud Computing e questo movimento NoSQL
hanno recentemente riproposto con vigore.
Rivoltando la frittata, non dobbiamo credere che il modello
relazionale ha avuto successo solo per virtu' proprie...
l'uomo giusto stava nella ditta giusta...
Va bene, vedremo come andra` a finire, per intanto voglio
vedere come si svacca l'HTML, nato per i documenti e
finito a suonerie & videoporno.
bye
[*]per le relative contro-critiche:
http://www.dcs.warwick.ac.uk/~hugh/TTM/Reactions-to-A-Call-to-Arms.html

 [...]
Ciao  Manlio

 E pensare che io stavo aspettando XHTML 2.0...
Son certe cose che leggi tipo queste:
http://www.456bereastreet.com/archive/200708/the_html_5_circus_why_i_left_and_rejoined_the_w3c_html_working_group/
specie il terzo commento che ti gelano le speranze...
E' curioso notare come sia l'SQL che l'HTML sono nati
come linguaggi con scopi e limiti ben definiti, ma si sono
successivamente evoluti verso linguaggi di programmazione
completi; sembra che nessuno voglia onorare il concetto
di separazione dei compiti. 

 [...]
Ciao  Manlio

 
L'algebra relazionale è servita a produrre i database relazionali, che 
sono strumenti nati in primo luogo per risolvere esigenze connesse agli 
aspetti economico-aziendali.
I NULL se ne stanno ben saldi perché servono, a prescindere da 
un'algebra che dai database resta comunque lontana.
Vi faccio solo un esempio: occorre un campo nuovo necessario per un 
piccolo sottoinsieme dei record di una tavola. Questo campo contiene una 
foregni key su una tavola esterna, che esula dal vostro controllo e non 
contempla un valore idoneo a descrivere cosa mettere nel nuovo campo 
quando non è rilevante.
Mi spiego meglio con un esempio: il 5% dei clienti ha un comune di 
spedizione della merce diverso da quello in anagrafe. I comuni stanno in 
una tavola codificata dall'ISTAT e non è possibile aggiungere il record 
"Comune non definito" perché farebbe crollare l'analisi sottostante a 
decine di procedure già faticosamente scritte e testate.
Il NULL vi servirà.

 
In questo caso prevedi un campo flag che contiene l'informazione
indirizzo di spedizione <> anagrafica

 Quindi tu spedisci la merce a "comune non definito"? Bello quel posto...
Il "comune non definito" rappresenta una soluzione al vincolo 
d'integrit� referenziale sul campo che contiene il codice istat del 
comune. Tieni presente che il codice di elaborazione documenti � 
normalmente scritto da linguaggi quantomeno procedurali e che la tavola 
dei comuni pu� avere tutti gli attributi necessari ad interagire con 
l'utente segnalando incongruenze gi� al caricamento dell'ordine 
d'acquisto e della relativa destinazione della merce.
Nella realt� degli ERP le cose sono molto pi� complesse, ma non mi 
sembra il caso di farti un corso qui: mi occorreva un esempio per 
ragazzi freschi di studi che hanno imparato che i NULL potrebbero anche 
non esistere e sono ancora turbati dalla notizia, mentre non potevo 
citare casi concreti che non conoscono. Giusto per fari capire, pensa 
solo a lavorare con catene di supermercati e prova a disegnare qualche 
tavola.

Andrea B. @wrk ha scritto:

L'indirizzo di spedizione, nel caso in cui sia uguale, varrà NULL?
Tieni presente che occorre un constraint di tipo not null sul campo del 
codice ISTAT del comune di spedizione per soddisfare la domanda 
iniziale. In caso contrario devo intervenire sulla cardinalità dei 
comuni, cosa impossibile senza ricorrere a una UNION.

 spedizione della merce diverso da quello in anagrafe.
Ma in quel caso non dovresti piuttosto creare una nuova tabella con 
dentro i riferimenti a Comuni e Clienti per quel cinque percento?

 comuni, cosa impossibile senza ricorrere a una UNION.
Era solo per seguire il tuo esempio evidenziando come il problema può
essere risolto senza NULL, nella pratica si potrebbero trovare soluzioni
più lineari.

 non mi sembra il caso di farti un corso qui [...] Giusto per fari capire,
Innanzitutto e` necessario piu' rispetto per chi piu' di tutti si
e` dato da fare qui e altrove; Davide Bianchi ha un'esperienza
e una carriera che gli altri la guardano col telescopio, altro che
corso sugli ERP. 

 decine di procedure gi� faticosamente scritte e testate.
Nella teoria relazionale, non ci sono "campi" opzionali, valori
nulli o numeri magici che modificano il significato delle colonne a
seconda del relativo valore.
La prima forma normale richiede un valore per ogni attributo,
altrimenti non puo' essere un'istanza del predicato
espresso dall'intestazione di tabella; il NULL non
fa altro che aggirare questo vincolo, solitamente
mascherando il fatto che si tratta in realta' di due tabelle
in una.
Il vincolo di integrita` referenziale serve esattamente ad
imporre che non si inseriscano dati farlocchi tanto per
riempire un form ed andare avanti, e` esattamente il
suo scopo e la sua obbligatorieta` E' UN BENE.
Il NULL causa problemi (almeno) tanto quanto un ipotetico
valore farlocco "Comune non definito"; sono egualmente errati.
L'esempio mostra semplicemente che un design errato
ne chiama un altro, e non c'e` rimedio ad un errore di progetto.
Lo scopo del modello relazionale e` che il database
e` in grado da solo di provvedere alla propria integrita`,
non tramite programma esterno.
Le righe non sono record, le colonne non sono campi,
le relazioni non servono per i join e la loro cardinalita` non e`
significativa; altrimenti e` credere che il database
sia un foglio di calcolo. 

 
Se vuoi replicare portando dei contenuti puoi farlo e puï¿œ servire. La 
risposta di Davide Bianchi mi ï¿œ sembrata irritante e superficiale, ma 
sono disposto a ricredermi volentieri e credo che se lo desidera potrï¿œ 
rispondermi da solo.
Il tuo post ï¿œ inutile, a meno che ti serva raccogliere la gratitudine di 
qualcuno che osservi dal telescopio. E francamente spero di no.

 dentro i riferimenti a Comuni e Clienti per quel cinque percento?
Sì, certo, in questo modo tutto funziona. La ragione per cui spesso 
ostacolo chi propone queste soluzioni, se non si tratta di relazioni 
"diversi a diversi", è che costa di più: pensa solo all'interazione 
DB/intefaccia utente o alla probabile necessità di definire una nuova 
classe nel software che si andrà a scrivere. Anche la lettura dei dati 
sarà leggermente più articolata e la documentazione del progetto più 
lunga come la successiva manutenzione. Nulla di tragico, ma la capacità 
di bilanciare attentamente costi e benefici è una delle qualità più 
importanti del progettista.
Il mondo reale ha bisogno di NULL non solamente perché i progettisti 
sono degli incapaci e per questo motivo tutti i database più importanti 
ne sono provvisti.

 
Sto parlando di database non di algebra. Ho letto Codd (e Date) in 
originale negli anni '80 e conosco bene il tuo punto di vista che ï¿œ 
pacifico.
Per evitare che le persone colte equivocassero, ho volutamente parlato 
di tavole e non di relazioni e mantenuto la terminologia coerente, 
parlando nel gergo di chi usa Oracle piuttosto che DBII e non di chi si 
guadagna il pane con le strutture algebriche. Non sono cosï¿œ ingenuo da 
fare polemica con Date, trent'anni dopo, in un NG dove pochissimi mi 
capirebbero e su un argomento dove la bibliografia specializzata ï¿œ 
piccola perchï¿œ non c'ï¿œ motivo di contentendere, mentre la produzione 
didattica ï¿œ enorme perchï¿œ gli studenti faticano a capire.
La mia tesi ï¿œ semplice: i database relazionali hanno bisogno dei NULL 
per motivi che non discendono solo dall'incapacitï¿œ di chi progetta 
database. Quasi nessuno mi ha risposto a tono, tu mi sembri 
perfettamente in grado, ma se non ti va ti capisco, il tema non ï¿œ tanto 
rilevante.
A beneficio di chi non lavora nel campo ho voluto inventarmi un esempio 
e tutti si sono interessati a quello senza pensare che serviva a 
descrivere un concetto che nell'industria dei DB ï¿œ pacifico. D'altra 
parte questo ï¿œ un NG.
Sulla tua conclusione sul foglio di calcolo dissento totalmente. Se vuoi 
dirmi come faresti a gestire il "comune di spedizione" (facciamo finta 
che sia uno e che sia opzionale) nel mondo reale, senza null e con 
"mezzi scarsi aventi usi alternativi", ti prometto che leggerï¿œ con 
attenzione.

 valore farlocco "Comune non definito"; sono egualmente errati.
Che il NULL _possa_ causare problemi credo sia palese.
Che li causi _sempre_ ï¿œ tutto da dimostrare.

 abbastanza difficile.
Sinceramente mi sembra un po' limitante ricondurre la teoria a Date vs 
Codd ;)
Testi molto validi su algebra relazionale e teoria di basi di dati ce ne 
sono parecchi. Tutti sottolineano i possibili e non rari problemi con 
l'(ab)uso di NULL ma nessuno ne vieta o sconsiglia l'uso, ove richiesto. 
Sostanzialmente la necessità di ricorrere a tuple dangling in caso di 
dati non ancora definiti/correlati/sincronizzati. Certo dovrebbe essere 
una casistica specifica e/o temporanea.
Ciao,
Pablo

 2. indirizzi.indirizzo deve essere NULL.
oppure aggiungi una terza tabella che contiene la relazione tra
nominativi e indirizzi e tagli la testa al toro:
Anagrafica (pk_nominativo, ...)
Indirizzi (pk_indirizzo, via, comune...)
Anagrafica_Indirizzi(fk_nominativo, fk_indirizzo)
così puoi avere tranquillamente un nominativo senza indirizzo e non
metti nessun NULL.
bye!

 [...]
Vero, ma aggiungere una relazione molti a molti quando non esiste una 
relazione molti a molti (forse l'esempio non � esemplare ;) sotto questo 
aspetto), solo per evitare di usare un NULL, � peggio di usare un NULL.
Sbaglio?
Ciao,
Pablo

 qualcuno che osservi dal telescopio. E francamente spero di no.
Hai appena ammesso di aver reagito con stizza, per cui non sei
il miglior esempio di limitarsi ai contenuti tecnici; per quanto
tu possa aver trovato sgradevole il post, lui almeno non ha dato
dell'ignorante a nessuno.
Non si tratta di un episodio isolato, gia` nei primi tuoi messaggi
su questo NG hai trattato gli altri come degli studentelli
imberbi col cervello lavato dalla teoria, che del mondo "reale"
poco ne sanno, trascurando che se uno dice qualcosa magari e`
perche` proprio l'esperienza conferma certe idee.
Io te l'ho fatto notare, sara` come prosegui che fara` la
differenza...
Il motivo per cui faccio questo non e` per ammirazione,
che rifuggo, ma un (poco altruistico?) voler avere un NG sano.
Per me il rispetto viene prima di tutto il resto, e la sua
mancanza spesso condiziona negativamente tutto il pensiero.
Gli argomenti si possono anche fare a brandelli, ma bisogna
sapere dove fermarsi. Non siamo distributori automatici
di teoria con obbligo di servizio. 

 Appena ho tempo la cerco.
Purtroppo mi son ricordato male, non era una comparativa
ma un articolo piu' generico; "What is a Distributed Database
System?" in Relational Writings 1985-1989.
Nella bibliografia dello stesso si fa riferimento ad un
articolo di Codd in preparazione all'epoca, "Why Distributed
Systems Are Relational". 

Sei tu che scrivevi sotto l'alias Pablo Xon qui tempo fa? 

 in preparazione all'epoca, "Why Distributed Systems Are Relational".
Ok, grazie comunque.
Ciao  Manlio

 Sei tu che scrivevi sotto l'alias Pablo Xon qui tempo fa? 
Sï¿œ, l'email ï¿œ la stessa.
Avevo aggiunto il "Xon" perchï¿œ era comparso un altro Pablo, prima ho 
sempre usato questo alias.
Ricordi la gradevole e sintetica discussione sulle licenze di mySQL ? ;)
Ciao,
Pablo

 Sbaglio?
Boh, dipende. Io dicevo solo per amor di completezza, non sono tra i
talebani dell'algebra relazionale :^)
Se uno proprio non vuole i null tra i piedi lo può anche fare, in fin
dei conti hai comunque il vantaggio di avere sì più tabelle ma più
"dense", e dal punto di vista dell'occupazione di spazio non penso
faccia gran differenza. D'altra parte hai uno sbocciare di join sulle
query che è un amore :^)
Credo che la risposta si possa dare solo andando a vedere cosa
esattamente stai modellando e che tipo di utilizzo del dato devi fare.
Bye!

 metti nessun NULL.
Ammetto che mi sto perdendo nella discussione, ma leggendoti mi viene
spontanea una domanda: cosa succede quando faccio una join oppure
definisco una vista per avere nome-indirizzo-comune?
Non ottengo comunque dei null?
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 tutto dipende da cosa vuoi ottenere.
Non dico di no, ma rapportandomi a quanto vedo solitamente in giro
direi che la query pi� utilizzata di un db del genere sarebbe quella
che tira fuori un sacco di null...


 tutto dipende da cosa vuoi ottenere.
Secondo me il problema e' proprio li': la teoria relazionale ti
dice che puoi risolvere qualsiasi situazione senza il null, ma
e' la sua applicazione rigorosa che diventa troppo onerosa
per i casi pratici (per via della serie di casi particolari
che vanno tutti gestiti), e questo imho non e' un bene.
Una teoria che prevede il null come valore ammissibile (aggiunto
"ad hoc" ai domini di ogni colonna) secondo me aiuta
ad avere una teoria piu' simile ai casi concreti.
Poi (correggetemi se sbalgio poiche' la mia preparazione
teorica e' di qualche annetto fa e decisamente arrugginita ;)
mi sembra che porterebbe altri vantaggi, ad esempio l'operatore
join sarebbe un'operazione chiusa tra relazioni-con-null
mentr nella teoria senza in null non lo e'.
ciao
Giacomo
PS.
davvero interessante questo thread, e' un po' che questo NG
languiva e ci voleva proprio una argomento stimolante! :)

 esattamente stai modellando e che tipo di utilizzo del dato devi fare.
Concordo, sottolineando per� che � ben diverso dal dire (non tu) che i 
NULL non vanno _mai_ usati.
Ciao,
Pablo

 mentr nella teoria senza in null non lo e'.
Non ho ben capito quale sia il vantaggio... :)
Comunque personalmente non sento parlare di "abolizione" del NULL da 
almeno 10 anni.
Ciao,
Pablo

 Non ottengo comunque dei null?
Se li vuoi utilizzi join aperti (left o right), se non li vuoi usi
solo il join puro. Ovviamente ottenendo risultati ben diversi. Sta a
te la scelta :^)
bye!

 ha scritto nel messaggio
news:a5647e04-16cb-4abd...@v25g2000yqk.googlegroups.com

Per esperienza mi trover� molto pi� spesso a vedere i NULL che a non
vederli, quindi usare trenta tabelle invece di una mi far� perdere solo
tempo. A questo punto un qualche NULL ogni tanto potrei pure decidere
di usarlo :-D


 di usarlo :-D
direi che c'e' molto buon senso in cio' ;^)
bye!

 mentr nella teoria senza in null non lo e'.
A prima vista non mi sembra che sia cosi': la completezza
relazionale (quella classica ossia senza null di alcun genere)
richiede che qualunque risultato di un'espressione
relazionale (quindi anche join) sia a sua volta una
relazione (chiusura transitiva). 

 a quello ottenuto! :)
Avremmo un codice enormemente piu' robusto anche in presenza
di NULL in tabella. 

 nemico ben definito onde coalizzare le masse).
Io ne ricordo piï¿œ o meno una l'anno e vedo che google condivide questi 
miei ricordi. Certo poi possiamo avviare un dibattito 
metafisico-teologico sul significato di "contesa"...
Ciao,
Pablo

 risolvere?
Sull'argomento e' apparso il seguente articolo:
http://www.programmazione.it/index.php?entity=eitem&idItem=43907
Faccio come al solito notare che quando menziona cose
come velocita', consumo di memoria e facilita' di setup, in
realta' non si sta parlando di modello relazionale di per se',
ma della relativa implementazione nei vari rdbms, che quindi
puo' essere piu' o meno buona, etc.
Dallo stesso sito segnalo un articolo che spiega come l'SQL puo'
essere usato le ricerche web usando Yahoo a mo' di DBMS, il che
come minimo depone a favore di avere un data sublanguage
separato dal linguaggio di programmazione:
http://www.programmazione.it/index.php?entity=eitem&idItem=43658
notare l'intuitivita' e la facilita' di adattamento:
SELECT data, titolo
FROM ricerca.notizie
WHERE query = "Pippo Baudo"
ORDER BY data
LIMIT 5
Praticamente chiunque abbia un'esperienza anche solo marginale
in SQL sa a colpo d'occhio cosa fa il codice sopra.
Vorrei proprio vedere i proponenti di no-SQL se riescono ad
ottenere una soluzione di equivalente potenza e semplicita'...
Come tutte le cose fatte male ma di successo, non ci
libereremo tanto presto dell'SQL.