Basic Elements of Oracle SQL, 9 of 10 (2024)

Schema Object Names and Qualifiers

This section provides:

• rules for naming schema objects and schema object location qualifiers
• guidelines for naming schema objects and qualifiers

Schema Object Naming Rules

The following rules apply when naming schema objects:

1. Names must be from 1 to 30 bytes long with these exceptions:
   • Names of databases are limited to 8 bytes.
   • Names of database links can be as long as 128 bytes.
2. Names cannot contain quotation marks.
3. Names are not case sensitive.
4. A name must begin with an alphabetic character from your database character set unless surrounded by double quotation marks.
5. Names can contain only alphanumeric characters from your database character set and the underscore (_), dollar sign ($), and pound sign (#). Oracle strongly discourages you from using $ and #. Names of database links can also contain periods (.) and "at" signs (@).

   If your database character set contains multibyte characters, Oracle recommends that each name for a user or a role contain at least one single-byte character.

   Note:

   You cannot use special characters from European or Asian character sets in a database name, global database name, or database link names. For example, characters with an umlaut are not allowed.

   See Also

   Create Primary Keys in SQL Server - SQL ServerGet Table Primary Key Column In SQLSQL Collation support in BizTalk360 and BizTalk ServerCase insensitive SQL SELECT query examples | alvinalexander.com

6. A name cannot be an Oracle reserved word. AppendixC, "Oracle Reserved Words", lists all Oracle reserved words.

   Depending on the Oracle product you plan to use to access a database object, names might be further restricted by other product-specific reserved words. For a list of a product's reserved words, see the manual for the specific product, such as PL/SQL User's Guide and Reference.

7. Do not use the word DUAL as a name for an object or part. DUAL is the name of a dummy table.
8. The Oracle SQL language contains other words that have special meanings. These words include datatypes (see "Datatypes"), function names (see "SQL Functions"), and keywords (the uppercase words in SQL statements, such as DIMENSION, SEGMENT, ALLOCATE, DISABLE, and so forth). These words are not reserved. However, Oracle uses them internally. Therefore, if you use these words as names for objects and object parts, your SQL statements may be more difficult to read and may lead to unpredictable results.

   In particular, do not use words beginning with "SYS_" as schema object names, and do not use the names of SQL built-in functions for the names of schema objects or user-defined functions.

9. Within a namespace, no two objects can have the same name.

   The following figure shows the namespaces for schema objects. Each box is a namespace. Tables and views are in the same namespace. Therefore, a table and a view in the same schema cannot have the same name. However, tables and indexes are in different namespaces. Therefore, a table and an index in the same schema can have the same name.

   
   

   Each schema in the database has its own namespaces for the objects it contains. This means, for example, that two tables in different schemas are in different namespaces and can have the same name.

   The following figure shows the namespaces for nonschema objects. Because the objects in these namespaces are not contained in schemas, these namespaces span the entire database.

   
   
10. Columns in the same table or view cannot have the same name. However, columns in different tables or views can have the same name.
11. Procedures or functions contained in the same package can have the same name, provided that their arguments are not of the same number and datatypes. Creating multiple procedures or functions with the same name in the same package with different arguments is called overloading the procedure or function.
12. A name can be enclosed in double quotation marks. Such names can contain any combination of characters, including spaces, ignoring rules 3 through 7 in this list. This exception is allowed for portability, but Oracle recommends that you do not break rules 3 through 7.

    If you give a schema object a name enclosed in double quotation marks, you must use double quotation marks whenever you refer to the object.

    Enclosing a name in double quotes allows it to:

    See Also

    Enable and disable Case Sensitive password in Oracle
    • Contain spaces
    • Be case sensitive
    • Begin with a character other than an alphabetic character, such as a numeric character
    • Contain characters other than alphanumeric characters and _, $, and #
    • Be a reserved word

    By enclosing names in double quotation marks, you can give the following names to different objects in the same namespace:

    emp"emp""Emp""EMP "

    Note that Oracle interprets the following names the same, so they cannot be used for different objects in the same namespace:

    empEMP"EMP"

    If you give a user or password a quoted name, the name cannot contain lowercase letters.

    Database link names cannot be quoted.

Schema Object Naming Examples

The following examples are valid schema object names:

enamehorsescott.hiredate"EVEN THIS & THAT!"a_very_long_and_valid_name

Although column aliases, table aliases, usernames, and passwords are not objects or parts of objects, they must also follow these naming rules with these exceptions:

• Column aliases and table aliases exist only for the execution of a single SQL statement and are not stored in the database, so rule 12 does not apply to them.
• Passwords do not have namespaces, so rule 9 does not apply to them.
• Do not use quotation marks to make usernames and passwords case sensitive. For additional rules for naming users and passwords, see "CREATE USER".

Schema Object Naming Guidelines

Here are several helpful guidelines for naming objects and their parts:

• Use full, descriptive, pronounceable names (or well-known abbreviations).
• Use consistent naming rules.
• Use the same name to describe the same entity or attribute across tables.

When naming objects, balance the objective of keeping names short and easy to use with the objective of making names as descriptive as possible. When in doubt, choose the more descriptive name, because the objects in the database may be used by many people over a period of time. Your counterpart ten years from now may have difficulty understanding a database with a name like PMDD instead of PAYMENT_DUE_DATE.

Using consistent naming rules helps users understand the part that each table plays in your application. One such rule might be to begin the names of all tables belonging to the FINANCE application with FIN_.

Use the same names to describe the same things across tables. For example, the department number columns of the sample EMP and DEPT tables are both named DEPTNO.