Opinion: Which SQL Server columns should be nullable #2: Avoid placeholder values

In my previous opinion post, I was discussing why magic values where a problem. They are often added by developers when they are trying to avoid having any NULL data in a database.

While discussing this, I think it’s worth also highlighting the overall dangers of placeholder values. These are values that aren’t magic values but are ones that are intended to be replaced at a later time.

If you use any of these, you need to have a solid process in place to:

  • Make them consistent and easily identifiable
  • Replace them in any database that’s heading towards production
  • Avoid them like crazy in production databases (and if you can’t do that, have a great process for finding any that leak out)

Here are some examples of what I’m talking about:

This one is quite nasty because it really has nothing to make it stand out from the containing text.

The main image above with the TV show is a more obvious one (or you’d hope so). No doubt it’s a little harder for them to detect the use of that one but it can’t be that hard, or they need to use another type of image that doesn’t require human detection.

One of my favorites is where people have used text generators, but then forgotten to replace the text. Here’s an example on a wine bottle:

This is the classic Lorem Ipsum text.

The problem here is that they wanted something that really made the mock-up of the bottle look like the real thing. Unfortunately, it really did. I am surprised that whoever printed the labels didn’t notice it though.

Ideally, if you have a good DevOps process, you might need to have a testing step that checks for the presence of any placeholder values before any data is published.

Before I leave this topic, for a little fun, Shopify published a link to some cute lorem ipsum style generators.

https://www.shopify.com.au/partners/blog/79940998-15-funny-lorem-ipsum-generators-to-shake-up-your-design-mockups

They did fortunately include my oldest favorite: Bacon Ipsum.

Next week, back to how NULL does/doesn’t fit with database design.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *