• As a developer and a DBA (I think a lot of developers are a bit of both nowadays) I make use of both techniques.  As others here have said there is a time and a place for either/both.

    Having null's in a table is not necessarily a sign of bad design, if you intended the nulls to mean something, and if you did, then on most occassions you would want the middle tier to see these values.  I do however make use of isnull when writing stored procs and views that are to be digested by a reporting layer, as I find working with nulls in reporting tools to be something of a pain most of the time.

    As far as putting code into SQL, why the hell not?  It's a damn site faster at doing some things than C#, VB etc. Besides which it's a nice way of spreading the processing load across multiple boxes.  Compare how many spare cycles you have on your web server, app server and data server and see what works for you.

    It's essentially the same argument people were having about VB.NET or C#, which should you use?  Well whichever one is right for the job, just like everything else.

    Usual disclaimer, just my opinion.

    Tony