One of my biggest pet peeves at work has to do with……data.  How it is treated, how it is protected.  Data is the most important resource a company has, because from data comes information.  As my favorite technical specialist (Tom Kyte for those of you who don’t know me) says, “Applications come and go.  Data persists.”  We have several applications that allow users to review, add to , delete, and update their data on-line.  These applications are pre-loaded with new data every year; data that comes from the field usually.

We are preparing to load one of these applications now, as it is time for the field to once again send us new data.  I listened to a conversation today that went something like this (names have been changed, no actual quotes are used here but it is the gist of the conversation):

Joan (Business Analyst):  This year we were wondering if you could do something again about allowing data to load on the initial build without checks.  It never comes in completely clean and we force the users to do error reporting and make them correct their data before accepting it online through the application.

Ben (I/T Supervisor and former developer):  It’s easy enough to temporarily disable constraints for the initial build.

I (a former developer and now a database administrator) have time and again stated “This is NOT a good practice at all – we are sending a message that we don’t CARE about the data.  We are introducing known bad data into our database.  We SHOULD NOT BE DOING THIS!”

People – IF your application requires fields to be not null when the users enter data THEN you should require the same fields to be not null on the initial build.  Period.  If you don’t START with clean data you have shot yourself in the foot.  If you allow users to pass you bad data they will then feel that data integrity is not important, and they will give you what you ask for – garbage.  Make them clean their data BEFORE it gets to the database.  Please.

I have had to endure the most annoying back-and-forth e-mail chains every time data is loaded into these applications every year (data is loaded new every year, old data is archived off, tweaks are made to the process – you know how it is).  It usually starts with data not showing up in the application – and usually ends up resulting in a response from the developer or myself saying “But field X is null and field Y is null and field Z has an X in it, so the application thinks this row is marked as bad and won’t display it.”  Or “the dob field is null and it isn’t supposed to be, so the user can’t navigate off the record until they provide a valid birth date”.  Nulls are fine IF YOU ARE GOING TO ALLOW THEM.  If one of your business rules stipulates that dob MUST be filled and MUST be a valid date, THEN MAKE SURE IT IS FROM THE BEGINNING.

Our data is our meat and potatoes.  It drives our organization, and enables us to suggest process improvements.  It sometimes drives legislation in our state.  We can’t afford to serve up bad data.

Data.  It’s what’s for dinner.