Choosing Column Data Type 1. CHAR vs. VARCHAR2 It's always a good idea to choose VARCHAR2, because CHAR appends spaces to the string shorter than defined length thus wasting space. There's no storage or performance advantage in using CHAR. The only "benefit" of CHAR is to save typing. If you have many VARCHAR2 fields and a few string types of length 1 (e.g. columns sex, employee_status), CHAR(1) stands out when you describe the table in Sqlplus. Since it's not possible to waste storage for CHAR(1), that may be the only time it makes sense to use CHAR. Benefits are as trivial as that. (Why is CHAR a data type in Oracle at all? It may be required by some SQL or RDBMS standard.) 2. CLOB vs. VARCHAR2 LOB is more cumbersome to manipulate than plain VARCHAR2, and (maybe up to the recent SecureFiles LOBs) less performant. Its internal storage and management mechanism is quite different from those of other data types. Unless your data is definitely longer than 4000 bytes, use VARCHAR2. 3. NUMBER precision and scale If there's no requirement on precision or scale, there's no need to specify that. It's not uncommon to see developers constantly requesting for expansion of the precision of NUMBER (and width of VARCHAR2 as well). It's an unnecessary hassle. Although a plain NUMBER type needs 21 bytes to store 1/3 (in fact, .3333... many 3's) and you may be advised to define precision, this is in reality never needed. When do you need to store such "accurate" numbers? In fact, when you do, as in case of temporary storage as a middle step in calculation, you do need as much precision as possible. 4. LONG, LONG RAW There was report of better performance for LONG/LONG RAW than CLOB/BLOB many years ago. If it was true, it probably no longer is, especially when you decide to use SecureFiles LOB, which becomes default in 12c. Due to numerous restrictions on LONG/LONG RAW, never use them. Consider LOB, and if the data is text and shorter than 4000 bytes, use VARCHAR2. 5. BINARY_DOUBLE, BINARY_FLOAT It's possible to get better performance by storing data as these types if your app does floating point calculation a lot. 6. DATE vs. TIMESTAMP If your data must be accurate down to millisecond, use TIMESTAMP. Otherwise use DATE. The storage for TIMESTAMP is 11 bytes (when millisecond part of the data is not 0 i.e. is present) while that for DATE is 7. Appendix 1: Store data in files or database? Store file data in files. A relational database is best used to store relational data, including metadata about the files, so that they can be joined and cross-referenced to other data. The data in files don't belong to this category. Secondly, RDBMS backup has a higher standard on consistency and is generally more resource intensive. Leaving files on the file system makes backup easier, and restore way much easier and faster. Lastly, LOB is more cumbersome to manipulate than plain varchar2 and number types, and (maybe up to the recent SecureFiles LOBs) less performant. The benefit of storing file data inside the database is that you can bring the data anywhere in one go, and in case of RAC, you don't need to worry about which node is used to store the files, if they must be on the database server. But the first benefit is too trivial. The second is irrelevant in most cases since the files are often accessed through a Web server, the natural location for those files. Q: If storing file data in files is preferred to storing it in the database, how can I make sure the files can only be accessed by going through a login process? A static URL directly pointing to the file can bypass this login. A: Mid-tier technology should be able to support this. Instead of a static URL in your web page, the URL can point to an action script with a parameter that identifies the file to be viewed, and the action script checks if the session ID or cookie is included before serving the file. For example, Oracle Support web site has this URL providing a PDF file: https://support.oracle.com/epmos/main/downloadattachmentprocessor?attachid=1964057.1%3AFLUID_APPROVAL_SETUP&action=inline The downloadattachmentprocessor action program has the logic to check if the user already logged in before showing the file (attachment) in the browser window. Appendix 2: Is it bad to set VARCHAR2 width too large? Yes. Oracle will change array fetch to one-row fetch if the anticipated row length exceeds the block size, even if the actual row length is short. See Jonathan Lewis' demo at http://www.freelists.org/post/oracle-l/RE-bytes-vs-chars,6