Excellent article.  Just one question - What if you're searching for Base64 encoded data in a column?  By definition Base64 is case-sensitive.  Of course you can turn off case insensitivity...

Thanks for the feedback!  I'm glad you found it helpful.

Thanks for the feedback!

I'm not sure that COUNT(1) is any faster than COUNT(*).  If you look at the query plan for the sample query in the...

The main reason I can think of is for questionnaires and the like, where you need to generate statistical analyses after they have been filled out by your users.  Marketing...

For this, the additional CHAR(1) column with your status/reason attribute will work quite nicely.  If the name does exist, populate your CHAR(1) column for that row with a designated indicator;...

Fair enough, but then why have any mark at all (SQL NULL or otherwise) - would it not make more sense to simply represent the missing data separately as...

Technically speaking, zero-length strings are suggested in the article as the actual physical CHAR/VARCHAR representation of a middle name consisting of exactly zero characters.  I think that a ZLS is...

Thank you for the feedback!

ANSI SQL doesn't provide differentiation for 'states' of missing data; only a mark indicating that the data is indeed missing.  In order to differentiate between different...

Thanks for the suggestion!  You can't go wrong with Date, Celko and the rest of the gurus.

I am with you on eliminating NULLs as much as possible; but as you also point...

I haven't had a chance to thoroughly test this myself yet, but Adam Machanic (MS MVP) has posted a blog on the topic.  He says that, according to his tests,...

Thanks for the feedback!  Excellent points.  I've also read, but haven't yet had a chance to verify, that ISNULL() performs better in some specific situations in WHERE clauses.  That might...

Performance-wise it wouldn't make a difference.

However, to get a TRUE/FALSE result from a where clause like "WHERE var1 = NULL" or a statement like "IF var1 = NULL", you would...

LIKE can absolutely use an INDEX, as long as your comparison string doesn't start with wild-cards.  i.e.,

LIKE '%george' -- cannot use an index

LIKE 'George%' -- can use an index

Excellent article, thanks for the advice!

Another problem with this concept being applied to network security is that, if someone does break through your security, it will be very hard to track down the break-in point...