Louis Davidson (@DrSql) had an excellent series on his blog on the Pillars of Database Design and the one of the key elements of his first pillar A Cohesive Design is to for data types to make sense.  I couldn’t agree more.  I have seen more problems caused by using a character type to hold dates or numbers.  The developers, in each case I’m sure, decided that they would verify the type in the application, and I would bet they did.  What they didn’t do, was consider the case where a user get access via MS Access or some other tool and now can enter/modify data outside the application.  This is how you end up with Nobember 17 or February 30 as a date, 1O (yes that’s an letter o) or A17 as a number.  Now when it comes time to query those values or use them in a WHERE or JOIN, what are you going to do?  You will get conversion errors if you try to convert them to the proper data type.  Here’s a recent thread on SQLServerCentral where you can see many of the problems using a “generic” data type causes.

Look if the column is supposed to store dates use the appropriate DATE data type, most RDBMS products have a few, and if it is supposed to store numeric data use the proper NUMERIC data type.  So if you are storing a person’s age you don’t need BIGINT or DECIMAL, SMALLINT will work fine.  This is one of the things a database is designed to help with, verification that data is of the correct type, don’t keep the database engine from doing what it is designed to do!

Thanks for your suppport!