We've all heard of dates. Not the kind with someone to whom you're attracted. No, I mean the kind that represent some relative position on the calendar. Now we've all seen what people do when faced with the extremely difficult task of working with dates. Short of programming in brainfsck, intelligent programmers use the built-in variety, be it in C#, Java, etc.

Sometimes, you need to be able to identify different parts of a date. But, given (let's use Java as an example) a java.util.Date, how on Earth can any reasonable person possibly figure out the year without too much grief? I mean, it's mathematically hard to convert all those milliseconds to years. There must be a better way to identify years!

Mick's co-worker decided that a database was required. Not only did he incorporate a database to figure out the year component of dates, he thought that each year needed to be explicitly identified...

 

Kris must work with the folks who work with Mick, because he worked on fixing a foreign key constraint issue, and was instructed to just add rows to the table that was causing the problem...

 

Of course, others have difficulties understanding the proper use of database tables for things beyond dates. Justus found this wonderful representation of catalog data:

 

Jon sent in a sample of a catalog table designed by Nigel who left shortly thereafter. Apparently, Nigel felt that each item in the catalog deserved it's own column in the table. Jon's pretty sure this will need a rewrite:

 

Still others feel that normalization is simply not an option. An anonymous submitter sent in something their offshore outsourcing company turned in; a table with 600 columns, including:

  • 50 float columns
  • 50 integer columns
  • 50 date-time columns
  • 100 bit columns
  • 100 money columns
  • 200 varchar(1024) columns
  • 50 XML columns

 

Of course, dates/years and normalization are notoriously difficult concepts. Booleans on the other hand... Shane found a Yes table which has no counterpart No table... It has one row with one column containing a single "Y"...

 

One of the strengths of databases is their ability to record events that have happened. Sam was tasked with bringing over a mailing list to a new site. Part of the system mails out newsletters to all subscribers each month. By the time Sam inherited it, about 300 newsletters had already been sent. Apparently, the developer thought it would be a good idea to keep track of every recipient of every newsletter, and so added a slew of extra rows of tinyint's to keep track of who had / had not received the mail.

 

Of course, while there are many right ways to do that, this is probably not one of them.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!