In generale si pensa ad un database come un'altro modo per vedere un foglio di lavoro... ma il database non è un foglie excel!
Ii database dovrebbe essere pensato dopo che si ha ben chiaro quello che si vuole fare nel nostro sistema o nella nostra applicazione.
Penso che il database non sia per "salvare dati" ma per "salvare i dato che servono".
Penso ci sia sempre una buona ragione ed un buon modo per non essere costretti a salvare dati NULL.
Cosa ci si guadagna a non avere NULL? Si guadagna in performance. Prima o poi - man man che si riempie - un database mal disegnato diventa lento.
Quello che sto dicendo non va tuttavia in contrasto con la definizione del DbNUll che sembra quasi che non debba esistere... tutt'altro!
Ha senso che esista il concetto del DbNUll... un conto è che non è corretto salvare dati NULL e un conto è che il database a fronte di un
interrogazione ci risponda con DbNUll (dato sconosciuto). Pensiamo al risultato di outer join ad esempio.
Rimane per tanbto sempre valido quando propostao qui "Lettura dei dati e DbNull".
Fortemente convinto di queste mie affermazioni ho trovato in giro un può di buona documentazione in merito a disegnare databse.
"Introduction to Relational Database Design"
http://www.edm2.com/0612/msql7.html
"Data Type Performance Tuning Tips for MS SQL Server"
http://www.sql-server-performance.com/datatypes.asp
"Optimizing Your Database Performance …the Easy Way"
http://www.dbazine.com/dbastore/18278.pdf
Per oggi ho pensato anche troppo... fa troppo caldo!