When you're defining a column, the first question you should ask isWhat data is possible or impossible for this column? For example, a "phone number" column should accommodate all possible phone numbers but no impossible ones; a "book title" column should accommodate uppercase conversion but not addition. Your second question should beGiven the answer to the first question, what data type is both efficient and portable for this column? For example, an elapsed-minutes column might be defined as INTEGER rather than INTERVAL because INTEGER is smaller and is more easily cast to a C data type.
This chapter is all about how you can choose the data type and size for a column without growing dependent on any DBMS's foibles. After discussing the general questions of column size and size variability, we'll look at the main built-in SQL data types: characters , temporals , numbers, bits, and "large objects" such as BLOBs. Then we'll consider factors that cause overhead regardless of data type, such as nullability and column order within a table definition. In our discussions, we'll highlight both storage and performance issues.