All objects follow the general gaming rules. In addition,
some objects have additional restrictions shown in the accompanying
tables.
Table 1. Database, database alias and instance naming rulesObjects |
Guidelines |
- Databases
- Database aliases
- Instances
|
- Database names must be unique within the location in which they
are cataloged. On Linux and UNIX implementations, this location
is a directory path, whereas on Windows implementations,
it is a logical disk.
- Database alias names must be unique within the system database
directory. When a new database is created, the alias defaults to the
database name. As a result, you cannot create a database using a name
that exists as a database alias, even if there is no database with
that name.
- Database,
database alias and instance name lengths must be less than or equal
to 8 bytes.
- On Windows, no instance
can have the same name as a service name.
Note: To avoid potential problems, do not use the special characters
@, #, and $ in a database name if you intend to use the database
in a communications environment. Also, because these characters
are not common to all keyboards, do not use them if you plan to use
the database in another language.
|
Table 2. Database object naming rulesObjects |
Guidelines |
- Aliases
- Audit policies
- Buffer pools
- Columns
- Event monitors
- Indexes
- Methods
- Nodegroups
- Packages
- Package versions
- Roles
- Schemas
- Stored procedures
- Tables
- Table spaces
- Triggers
- Trusted contexts
- UDFs
- UDTs
- Views
|
- Lengths for identifiers for these objects
must be less than or equal to the lengths listed in: SQL
and XML limits. Object names can also include:
- Valid accented characters (such as ö)
- Multibyte characters, except multibyte spaces (for multibyte environments)
- Package names and package versions can also include periods (.),
hyphens (-), and colons (:).
For more information, see Identifiers.
|
Table 3. Federated database object naming rulesObjects |
Guidelines |
- Function mappings
- Index specifications
- Nicknames
- Servers
- Type mappings
- User mappings
- Wrappers
|
Lengths for these
objects must be less than or equal to the lengths listed in: SQL
and XML limits. Names for federated database objects
can also include: - Valid accented letters (such as ö)
- Multibyte characters, except multibyte spaces (for multibyte environments)
|
Delimited identifiers and object names
Keywords can be used. If a keyword is used in a context where it
could also be interpreted as an SQL keyword, it must be specified
as a delimited identifier.
Using delimited identifiers, it is possible to create an object
that violates these naming rules; however, subsequent use of the object
could result in errors. For example, if you create a column with
a + or - sign
included in the name and you subsequently use that column in an index,
you will experience problems when you attempt to reorganize the table.
Additional schema names information
- User-defined types (UDTs) cannot have schema
names longer than the lengths listed in: SQL
and XML limits.
- The following schema names are reserved words
and must not be used: SYSCAT, SYSFUN, SYSIBM, SYSSTAT, SYSPUBLIC.
- To avoid potential problems upgrading databases
in the future, do not use schema names that begin with SYS. The database
manager will not allow you to create triggers, user-defined types
or user-defined functions using a schema name beginning with SYS.
- It is recommended that you not use SESSION as a schema name. Declared
temporary tables must be qualified by SESSION. It is therefore possible
to have an application declare a temporary table with a name identical
to that of a persistent table, in which case the application logic
can become overly complicated. Avoid the use of the schema SESSION,
except when dealing with declared temporary tables.