By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,954 Members | 1,248 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,954 IT Pros & Developers. It's quick & easy.

Managing Nulls in the DB

P: n/a
Hi all,

Do you think the best way to avoid the problems of nulls in the database is
just to provide default values via the db schema?

Alternatively, is it better to allow nulls, seeing as the "absence" of data
is an entirely valid and useful value?

If the later is true, is there a better way to handle nulls that doing this
for each and every column of each and every table? I'm hoping there is
something a bit more intuitive or something that would write this crap for
me the way I want (without me having to learn a CG scripting language for
customised templates)?

I'm really more interested on everyones thoughts on the first two questions
though.

Many thanks all

Simon
Nov 16 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"Simon" <sh856531@microsofts_free_email_service.com> wrote:
Do you think the best way to avoid the problems
of nulls in the database is just to provide default
values via the db schema?


What makes nulls a "problem"?

P.
Nov 16 '05 #2

P: n/a
What I mean is, they are a pain in the ass to have to protect against. For
example the only way I know how to avoid getting an invalid cast exception
when I do this and the value is null:

string myString = currentRow["mycolumn"];

is to wrap it in a :

if(!Convert.IsDbNull){

}
else{

}
This needs to be done for each and every column access unless you know that
nulls are defineately not allowed.

I'm wondering if there is a better way to handle nulls in general.

Do i disallow them at the db level or do I just live with the fact that they
might be there?

Thanks

S
Nov 16 '05 #3

P: n/a
If you're using SQL Server, you can use the special types in
System.Data.SqlTypes. For example, SqlInt32 can legitimately be null,
whereas a regular Int32 can't.

Also, think about writing classes to encapsulate your database tables
(business objects). That way, other code can just call methods on an
object of the class, and you only have to write the SQL and column
accesses once.

Disallowing nulls in the database seems a bit extreme, since they're
useful things.

P.
Nov 16 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.