Rules exist for the naming of
all database objects, user names, passwords, groups, files, and paths.
Some of these rules are specific to the platform you are working on.
For example, regarding the use of upper and lowercase
letters in the names of objects that are visible in the file system
(databases, instances, and so on):
- On UNIX platforms,
names are case-sensitive. For example, /data1 is
not the same directory as /DATA1 or /Data1
- On Windows platforms,
names are not case-sensitive. For example, \data1 is
the same as \DATA1 and \Data1.
Unless otherwise specified, all names can include the following
characters:
- The letters A through Z, and a through z, as defined
in the basic (7-bit) ASCII character set. When used in identifiers
for objects created with SQL statements, lowercase characters "a"
through "z" are converted to uppercase unless they are delimited with
quotes (")
- 0 through 9.
- ! % ( ) { } . - ^ ~ _ (underscore) @, #, $, and space.
- \ (backslash).
Restrictions
- Do not begin names with a number or with the underscore character.
- Do not use SQL reserved words to name tables, views, columns,
indexes, or authorization IDs.
- Use only the letters defined in the basic ASCII character
set for directory and file names. While your computer's operating
system might support different code pages, non-ASCII characters might
not work reliably. Using non-ASCII characters can be a particular
problem in distributed environment, where different computers might
be using different code pages.
- There are other special characters that might work separately
depending on your operating system and where you are working with
the DB2® database. However,
while they might work, there is no guarantee that they will work.
It is not recommended that you use these other special characters
when naming objects in your database.
- User and group names also must follow the rules imposed
by specific operating systems. For example, on Linux and UNIX platforms,
characters for user names and group names must be lowercase a through
z, 0 through 9, and _ (underscore) for names not starting with 0 through
9.
- Lengths must be less than or equal to the
lengths listed in: SQL
and XML limits.
- Restrictions on the AUTHID identifier: In DB2 Version 9.5 and later, you can
have a 128-byte authorization ID. However, when the authorization
ID is interpreted as an operating system user ID or group name, the
operating system naming restrictions apply. For example, the Linux and UNIX operating systems can contain up to 8 characters
and the Windows operating
systems can contain up to 30 characters for user IDs and group names.
Therefore, while you can grant a 128-byte authorization ID, you cannot
connect as a user that has that authorization ID. If you write your
own security plug-in, you can use the extended sizes for the authorization
ID. For example, you can give your security plug-in a 30-byte user
ID and it returns a 128-byte authorization ID during authentication
that you can connect to.
You also must consider object naming rules, naming rules in an
NLS environment, and naming rules in a Unicode environment.