Practical .NET

What's wrong with nulls?

You need the null value to descibe an object with "no value". E.g. lets say you have an amount column in which 0 is a valid amount. How would you tell the difference between a valid zero value and no value?

Anyway, I often code around the null problem by designing my table entity classes to use a default in case of null, but this is only because value types in c# can't be null (at least v1.1).

Nothing wrong with nulls. I'm sure they're useful. I just haven't found any use for them. I've been doing DB for 8 years now, and never once have *needed* a null value.

Yeah, I realize that there's a difference between a zero-length string and a null, but seriously, what's the point? One more level of checks?

You don't need nulls, you can use default values instead. Look at it as just a different way to design.

e.g. "select * from someTable where someFKID > 0"

versus "select * from someTable where someFKID is not null"

BTW, I ran across this in the SQL Help for nulls:

"Important! To minimize maintenance and possible effects on existing queries or reports, it is recommended that you minimize the use of null values. Plan your queries and data-modification statements so that null values have minimal effect."

So it looks like you are justified not to use them, but I'm not sure I would go as far as to say a database design is poor ONLY because it allows null values.

In your case, since the null values are hosing the app the real question is, "who was the poorer designer, the database developer or the coder?". Is the app suffering because of poorly designed use of nulls in the database or poor handling of null values in the application?

Point well taken.

I'm starting to realize that the app (in its original state) was *fairly* solid. Flexible, yes. Nicely done from an implementation perspective. It's when the mods started to happen that all went haywire.

I also do typically use default values. (especially for dates).

Thanks for your feedback on all this!