Should fields that are set to Not Null also have a constraint refusing empty strings?

Question

Any field that I would expect a value (Like an orderNumber or customerNumber) I would set as not nullable.

If I'm expecting the value of the field to be not null, shouldn't I also always have a constraint that does not allow for zero length strings or space only strings?

Answer 1

I hate empty strings.

That being said, disallowing empty string as a policy doesn't solve the underlying problem; which is "garbage in=garbage out".

If I'm a developer who knows what I'm not allowed to use but I think it's stupid, I'll find an exception.

• no empty string? I'll insert 'x'
• no single character? I'll insert 'xx'
• some regex filter abomination? random text algorithms are cheap.

Disallow empty string (or other patterns) if you have client issues with garbage data. But whenever you're setting procedural rules to pre filter crap, make sure you reduce the demand as well as the supply. Figure out why people are demanding crap data and give them an alternative instead of fighting them at the tap.

---

Alternately you could use an additive check constraint or a custom data type to enforce certain input constraints 🤷‍♂️

Answer 2

If I'm expecting the value of the field to be not null, shouldn't I also always have a constraint that does not allow for zero length strings or space only strings

Yes. Yes you should.

It's ANSI standard behavior to enable storing empty strings, but that doesn't mean it's a good idea. And you especially should not allow both Null and '' in a column.

And note that because strings are compared without trailing spaces,

 check (SomeCol<>'')

suffices for both.