COMMON DATA MODELING PROBLEMS - A Developer's Guide to Data Modeling for SQL Server - page 179

Extra unneeded storage overhead

■

No data integrity constraints

■

The need to convert the data to and from varchar

■

Slow join performance

■

Let's take a closer look at each of these problems.

Extra Unneeded Storage Overhead
Depending on the type of data being stored, using the wrong data type can
add extra storage overhead. If you are holding phone numbers in the form
of 1235557890, it means that you save 10 characters each time a phone
number is stored. You have a few good data type choices when storing
phone numbers in this way; you could use a varchar, a char, or a bigint.
Recall from Chapter 3 that a bigint requires 8 bytes of storage, and the
storage for the char and varchar data types depends on the data being
stored. In this case, the 10-digit phone number would require 10 bytes of
storage if you use the char, and 12 bytes of storage if you use the varchar.
So just looking at the storage requirements dictates that we use a big-
int. There are other considerations, such as the possible length of the for-
matted number. If you want to store numbers in a different format, such
as [phone], then you would need one of the string data types.
Additionally, if you might store international numbers, which tend to be
longer than 10 digits, you might consider using varchar. In that way, the
shorter number takes up less space on disk and you can still accommodate
longer numbers.
There are other things to consider, and each situation is unique. All we
want to illustrate here is the extra storage overhead you would incur by
using the string types.
A word of caution: Don't go too far when streamlining your storage.
Although it is a good practice to avoid unneeded storage overhead, you
don't want to repeat the mistake that made Y2K such a big deal. Rather
than store all four digits of the year when recording date information, pro-
grammers stored only the last two digits to conserve space. That worked
when the first two digits were always 19, but when the calendar pointed
to the need for four digits (2000), we all know what happened (in addition
to COBOL programmers getting rich): A lot of code had to be rewritten to
expand year storage. In the end, we are saying that you should eliminate
unneeded storage overhead, but don't go to extremes.