When you create a table, you should give it a name that indicates what data the table stores. Table names must be unique in a geodatabase—you can't have more than one table with the same name.

The name that you indicate when you create the table in ArcGIS Desktop, however, is not the name of the table as it appears in the geodatabase. The geodatabase appends the name of the database and the name of the schema in which the table is stored. This is referred to as the fully qualified table name. For example, if user Werther creates a table called alpacas in the SDE database, the name of the table in the geodatabase will be

sde.werther.alpacas

Therefore, it is possible for other users to create tables called alpacas because the tables they create will have their user names appended to the table names. For example, if user Gretchen created her own alpacas table, the name in the database would be

sde.gretchen.alpacas

However, it is not recommended that you reuse table names even if they are stored in different schema or databases. In this example, if both tables contained information about alpacas, there would be no reason to have two separate tables. If the data was distinctly different between the two tables, the table names should reflect that.

Additional rules

• Names must begin with a letter, not a number or special character such as an asterisk (*) or percent sign (%).
• Names should not contain spaces.
If you have a two-part name for your table or feature class, connect the words with an underscore (_), for example, garbage_routes.
• Names should not contain reserved words such as select or add.
Consult your DBMS documentation for additional reserved words.
• Names are limited to 32 characters.
The database and schema names do not count toward your 32 characters. So in the examples above, you could have 32 characters to the right of the second dot (.). Although names of this length are allowed, they are not recommended. As you can see in the field names section of Defining fields in tables, certain column names have the database, schema, and table names appended to them. If your table name alone was 32 characters, these column names would be unmanageably long.

NOTE: Table or feature class names with the following prefixes are not supported: "gdb_", "sde_", "delta_".

Aliases

When you create a table or feature class in the geodatabase, you can assign an alias to it. An alias is an alternate name. If you assign an alias to a table or feature class, that is the name users will see when they add it to ArcMap. Users can still look up the name of the table or feature class by going to the Source tab of the Layer Properties dialog box.

Tip

• Geoprocessing methods exist to let you validate table and field names. See the topic Validating table and field names for more information.

Feature types are only defined for feature classes and are defined at the time of feature class creation. They specify what type of geometry will be stored in the feature class.

You should choose a feature type that best represents the real-world object you are trying to symbolize on your maps. This could vary depending on the map scale with which you use the feature class. You should also take into consideration the type of analyses you may want to perform with the data.

The following table contains a list of the types of features you can specify for a feature class, along with descriptions of typical objects or concepts represented with that feature type. A third column contains notes on the sort of analyses or relationships you can create or perform only with this feature type.

Feature type	Real-world object or concept	Unique spatial analyses or relationships
Polygons	Objects or places that have area such as water bodies, jurisdictional or service area boundaries, wildlife ranges, or flood zones	Union with other polygon features Symmetrical differences Clip other features with
Lines	Linear objects such as rivers, streets and highways, utility lines, or survey transects	Use as edge feature sources for networks Model flow
Points	A narrowly localized position or spot such as a survey marker, sample point, telephone pole, or individual plant	Generate Thiessen polygons from Use with survey data (Survey Analyst) Use as junction feature sources in a network
Multipoints	An object or place that is composed of multiple localized positions, having the same attributes; for instance, a stand of the same species of tree, an island chain, multiple buildings in the same office complex, or lidar or sonar point clusters
Multipatches	Three-dimensional features such as buildings, mountains, water tables, and planets	3D analyses to derive contours, produce a hillshade, or analyze a viewshed or volume Cannot participate in a topology Cannot snap other features to
Annotation	Place or object names or identifiers such as street names, hydrant ID numbers, land values, or elevation	Can be linked to specific features When combining annotation feature classes, must all use the same label engine, standard or Maplex
Dimensions	Measurements such as distances, lengths, widths, and depths	A specific type of annotation used only for showing distances and lengths

You may find you need to have feature classes of different feature types to represent the same data. For example, if you usually create maps at a scale at which it makes sense to use a polygon feature class to represent city parks (approximately 1:25,000 to 1:100,000) but you sometimes need to create maps at a scale at which you need the parks to be shown as points (approximately 1:250,000 to 1:500,000), you could create a second parks feature class that uses centroid points to represent the location of the parks.

Or you may find for mapping purposes you need data represented in one feature type, but to perform certain analyses, you need the same data represented in a different feature type. For example, you may have a river feature class that stores the rivers as lines. That works fine for modeling flow or analyzing where rivers cross other features, but if you need to perform any sort of area analysis, such as clipping or calculating the area of your soils polygon feature class that is covered by rivers, you'll need to also model your rivers as polygon features so they have area, not just length.

Tables that store spatial data, such as those that make up feature classes, possess properties that define where the data is located in space. These properties include:

• Geometry type—Whether the features are points, lines, polygons, multipoints, or multipatches
(For information on geometry types, see the geometry subsection of Geodatabase field data types.)
• X,y coordinates—The data's location in two-dimensional space
• Z-coordinates—The data's location in the third dimension
• M-coordinates—Measures that can be used to calculate distances along line features
(For an explanation of x-, y-, z-, and m-coordinates, see Feature class basics.)
• A spatial reference—Includes a coordinate system; x-, y-, z-, and m-tolerance values; and x-, y-, z-, and m-resolution
(For details on spatial references, see the Spatial references in the geodatabase section of this help.)

Together, these properties allow you to find the location of a given feature on the earth.