This describes the naming conventions that should be used on remaining homeworks and the project when creating table and column names. They are based on standard industry practices and what the instructor has found to work well.

1. Underscores: Words in a column or table name should be separated by underscores. For example, PART_PRICE is better than PARTPRICE. This is not always clear. Should it be SALESREP or SALES_REP? Arguments can be made for both. When in doubt, use underscores.
   
   
2. Table names: Table names should be descriptive. They should also be singular. For example STUDENT is better than STUDENTS. Generally, complete words should be used in table names, unless this makes the table name too long (say, more than 16 characters). If a table name is too long then it is acceptable to abbreviate some or all of the words in the name.

   For each table define a short prefix that is unique to that table. Prefixes are used to name the columns in a table. Examples are STU or STDNT for the STUDENT table, or PREF_RTLR for a table named PREFERRED_RETAILER.
   
   

3. Column names: Column names, like table names, should be descriptive. However, we encourage the use of abbreviations and acronyms in column names in order to keep them a manageable length.

   All column names in a table, with the possible exception of foreign keys (see below), should start with that table's prefix. For example, the STUDENT table might have columns called STU_LAST_NAME, STU_FIRST_NAME, STU_MID_INITIAL, and STU_ID;
   
   

4. Abbreviations and Acronyms: Abbreviations and acronyms should be avoided in table names, unless using full words makes the table name too long. Abbreviations and acronyms are encouraged, but not required, in column names.

   The main rule here is be consistent. If a word is abbreviated anywhere then it should be abbreviated everywhere, and in the same way. The exception to this is table names. It is acceptable to abbreviate a word in column names and to spell it out in table names. The same rules apply to acronyms.
   
   

5. ID/Number/code columns It is often up to the database designer whether something should be called an ID, a number, or a code. Should student ID numbers be STU_ID, STU_NUM, STU_CODE, or STU_ID_NUM? Use the following guidelines to determine which to use:
   1. Does the attribute have a name that is already in wide use? If it does, then use that name.
   2. If the field will contain mnemonic abbreviations (such as "CIS" for "Computer and Information Science") then lean towards using code.
   3. If no name is already in wide use, then use your intuition about what to name the field.
   4. If no name is already in wide use, and you have no intuition, then favor using ID instead of number or code.

   Never use NO as an abbreviation for number. Use NR, NUM, or NMBR instead. NO causes confusion because it makes the field appear as if it might contain a yes/no value.
   
   

6. Foreign Keys Two main standards exist for the naming of foreign key fields.
   1. Name the column exactly as it occurs in the table where it is a primary key. For example, in the ENROLL table which keeps track of which students are taking which sections, the columns might be STU_ID, SECT_ID, and ENR_GRADE.
   2. Include the table's prefix in the column name and make it descriptive. With this approach, the ENROLL table might have columns called ENR_STU_ID, ENR_SECT_ID, and ENR_GRADE.

   Pick one and use it consistently. Of these 2 approaches I favor the second. It makes it clear which column belongs to which table for all columns. It also works in all situations (unlike the first approach). If we were to use the first approach to rename the columns in the sales reps table (from the SQL textbook), what would we call the column with the sales rep's manager's ID in it?