When you create feature classes and tables, you select a data type for each field. The available types include a variety of number types, text types, date types, binary large objects (BLOBs), or globally unique identifiers (GUIDs). Choosing the correct data type allows you to correctly store the data and will facilitate your analysis, data management, and business needs.
The data types explained in this topic include the data types available when creating a feature class or table with ArcGIS. If you store your data in a database or a geodatabase in a database management system (DBMS), ArcGIS data types and the data types of the DBMS might not match directly. The types are matched to the closest data type available in the DBMS. This process is referred to as data type mapping. In this process, it is possible that the values will be stored in the DBMS as a different type, applying different criteria to the data attribute. As a result, the data type you see in the table or feature class properties in ArcGIS Pro may change from what you initially defined.
Other data storage formats, such as shapefiles or DBF tables, have different data type limitations. Be sure you know the data type and size limitations of your destination storage format when moving data between data storage types.
Numbers
You can store numbers in one of four numeric data types:
- Short integer
- Long integer
- Float (single-precision floating-point numbers)
- Double (double-precision floating-point numbers)
In choosing the data type, consider the need for whole numbers versus fractional numbers. If you only need to store whole numbers, such as 12 or 12,345,678, specify a short or long integer. If you need to store fractional numbers that have decimal places, such as 0.23 or 1234.5678, specify a float or a double.
When choosing between a short and a long integer or between a float and a double, choose the data type that takes up the least storage space. This not only minimizes the amount of storage required but also improves performance. If you need to store integers between -32,768 and 32,767 only, specify the short integer data type, because it takes up only 2 bytes, whereas the long integer data type takes up 4. If you need to store fractional numbers between -3.4E38 and 1.2E38 only, specify the float data type, because it takes up 4 bytes, whereas the double data type takes up 8. The following table lists data types, their ranges, and storage requirements. The ranges listed are for file and mobile geodatabases. Ranges differ slightly in databases and enterprise geodatabases.
| Data type | Storable range | Size (bytes) | Applications |
|---|---|---|---|
Short integer | -32,768 to 32,767 | 2 | Numeric values without fractional values within specific range; coded values |
Long integer | -2,147,483,648 to 2,147,483,647 | 4 | Numeric values without fractional values within specific range |
Float (single-precision floating-point number) | Approximately -3.4E38 to 1.2E38 | 4 | Numeric values with fractional values within specific range |
Double (double-precision floating-point number) | Approximately -2.2E308 to 1.8E308 | 8 | Numeric values with fractional values within specific range |
If you're specifying numeric fields for a table in a file or mobile geodatabase, you need only specify the data type. If you're specifying numeric fields for a database or enterprise geodatabase, also specify the precision (the maximum length of the field) and scale (the maximum number of decimal places).
Specifying the precision and scale allows you to restrict the range of values and number formats a field can accept, giving you greater control. For example, if you specify a float with a precision of 4 and a scale of 2, the field will accept 12.34. If you try to enter 12.345 into the field, an error message will display, as this exceeds the maximum number of digits and decimal places allowed. On the other hand, if you specify a float with a precision of 5 and a scale of 3, the field will let you enter 12.345.
Data types and their possible precision and scale values are listed in the following table. Use this table to help you choose data type, precision, and scale:
| Data type | Precision (field length) | Scale (decimal places) |
|---|---|---|
Short integer* | 1–5 (Oracle, Microsoft SQL Server); 5 (IBM Db2); 1–4 (PostgreSQL) | 0 |
Long integer | 6–10 (Oracle); 6–9 (Db2, SQL Server); 5–9 (PostgreSQL) | 0 |
Float | 1–6 | 1–6 |
Double | 7+ | 0+ |
*By default in ArcGIS Pro, short integers are created with a precision of 5. However, short integer columns can only store values within the range of -32,768 to 32,767. Therefore, you cannot store a value greater than 32,767 or less than -32,768 in a short integer field, even if you set the precision to 5. There is no reason for you to specify a precision for short integer columns created in ArcGIS Pro on any database except Oracle. There is no reason to specify a precision for long integer columns created in ArcGIS Pro on SQL Server or PostgreSQL databases.
The following table provides examples of number ranges and how you can store them in a database or enterprise geodatabase:
| Range | Data type | Precision (field length) | Scale (decimal places) |
|---|---|---|---|
0 to 99 | Short integer | 2 | 0 |
-99 to 99* | Short integer | 3 | 0 |
-32,768 to 32,767* | Short integer | 5 | 0 |
-99,999 to 99,999* | Long integer | 5 | 0 |
0.001 to 0.999 | Float | 4 | 3 |
1,000.00 to 9,999.99 | Float | 6 | 2 |
-123,456.78 to 0* | Double | 9 | 2 |
0 to 1,234.56789 | Double | 9 | 5 |
*Negative numbers require additional precision to store the negative sign.
Computers can only store a limited number of digits, depending on the storage space being allocated. Fields of data type double in databases and geodatabases can precisely store numbers that contain up to 15 digits only, because this is the longest number that can fit into 8 bytes of storage space. Numbers that have more digits than this are rounded and stored in a format similar to scientific notation, making them approximate numbers only. For example, if you enter the 20-digit number 12,345,678,901,234,567,890, it is rounded and stored as the 15-digit number 1.23456789012346E+19. The coded value at the end, E+19, defines the placement of the decimal point.
Floats in file or mobile geodatabases can precisely store numbers that contain up to 6 digits only. For example, you cannot store the number 123,456.7 precisely in a float field, because this number contains more than six digits. You can enter the number into a float field in a file geodatabase, but it will be rounded to 123,457, a number containing the permissible 6 digits. If you need to store this number precisely, you can store it in a double field. Float fields in enterprise geodatabases and databases do not allow you to enter more digits than the precision for the field, so no rounding takes place.
Text
A text field represents a series of alphanumeric symbols. This can include street names, attribute properties, or other textual descriptions. An alternative to repeating textual attributes in a geodatabase is to establish a coded value. A textual description would be coded with a numeric value. For example, you might code road types with numeric values by assigning a 1 to paved improved roads, a 2 to gravel roads, and so on. This has the advantage of using less storage space in the geodatabase; however, the coded values must be understood by the data user. If you define your coded values in a coded value domain in the geodatabase and associate the domain with the integer field storing your codes, the geodatabase will display the textual description when the table is viewed in ArcGIS Pro.
Learn more about subtypes and attribute domains.
The characters used for text vary by language. To allow text to more easily convert between languages, ArcGIS uses Unicode to encode characters.
Dates
The date data type can store dates, times, or dates and times. The default format in which the information is presented is mm/dd/yyyy hh:mm:ss and a specification of AM or PM. When you enter date fields in the table through ArcGIS, they are converted to this format.
BLOBs
A BLOB is data stored as a long sequence of binary numbers. ArcGIS stores annotation and dimensions as BLOBs, and items such as images, multimedia, or bits of code can be stored in this type of field. You need to use a custom loader or viewer or a third-party application to load items into a BLOB field or view the contents of a BLOB field.
Object identifiers
The object ID field is maintained by ArcGIS and guarantees a unique ID for each row in the table. When you look at a table or a layer's attribute table, you usually see the object ID field listed under the aliases of OID or ObjectID for tables and FID for layers. Key functions, such as scrolling and displaying selection sets, depend on the presence of this field.
It should be noted that most ArcGIS Pro functionality, such as using the Identify tool, requires the object ID to be unique. Therefore, caution should be used when working directly with the database outside of ArcGIS so that object IDs are not duplicated. For example, when creating views with a one-to-many relationship, there is the possibility that object IDs will be duplicated. This will cause inconsistent behavior in ArcGIS Pro functionality.
When you add a database table to the map, an object identifier is needed. If ArcGIS cannot find a not null, integer field to use as an object identifier, you will be prompted to choose a field to be used as the object identifier. See Choose a unique identifier field for a query layer for more information.
Global identifiers
Global ID and GUID data types store registry-style strings consisting of 36 characters enclosed in curly brackets. These strings uniquely identify a feature or table row within a geodatabase and across geodatabases. This is how features are tracked in one-way and two-way geodatabase replication. Developers can use them in relationships or in any application requiring globally unique identifiers. In a relationship, if a global ID field is the origin key, a GUID field must be the destination key. You can add global IDs to a dataset in a geodatabase by using the Add Global IDs geoprocessing tool. The geodatabase will then maintain these values automatically. You can create the GUID field as well, but you must maintain its values.
Databases with a native GUID data type, such as SQL Server, store global ID and GUID values as 16 bytes. Databases without a native GUID data type store them as 38 bytes.
Some notes on global IDs
- GUID fields can be added to geodatabase datasets using the fields view, or the New Field command in the table window.
- You can add global IDs for stand-alone feature classes, tables, and attributed relationship classes in geodatabases. Global IDs cannot be added to individual datasets in a feature dataset; they can only be applied on the entire feature dataset.
- Global IDs cannot be added to tables in a database.
- If a global ID column already exists, the tool leaves the old column; it doesn't drop the existing global ID column and add a new one.
- If you add a feature class to a feature dataset in a geodatabase and want to add a global ID column to it, you need to run the Add Global IDs tool on the feature dataset. This adds a global ID column to the new feature class and any feature classes that don't already have a global ID column. Feature classes that already have a global ID column remain unchanged.
- Copying and pasting, data extraction, and XML workspace exporting and importing preserve global ID values in the output geodatabase. Other data exporting and importing methods do not preserve these values.
Fields of type raster
Unlike a hyperlink that only links a feature's field to an image, a field type raster can actually store the raster data within or alongside the geodatabase. To learn more, see Adding raster datasets as attributes in a feature class.
Note:
Mobile geodatabases do not support raster columns; however, they do support the use of attachments to associate nongeographic data such as photos or documents to a feature.Learn more about working with the Attachments geoprocessing tools.
Geometry
In ArcGIS, the geometry data type indicates the type of geometry—point, line, polygon, multipoint, or multipatch—the table stores. The field stored as geometry type is named SHAPE when created through ArcGIS.
Geometry is the data type used by ArcGIS. For example, if you choose Polygon Features for a new feature class, the SHAPE field added by default will have an ArcGIS data type of Geometry.
For the Geometry Type property of the Create Feature Class tool, the geometry type will be listed as Polygon.
If you had created a feature class with a different feature type—line, point, multipoint, multipatch, dimension, or annotation—the geometry type for the SHAPE field would change accordingly—to line, point, multipoint, multipatch, or polygon for dimension and annotation.
When you create a geometry field in a feature class in a database or enterprise geodatabase, there is an additional data type to consider: the database data type. How the value of the SHAPE field is stored in the DBMS depends on the geometry storage type used by the DBMS. When you create a feature class in an enterprise geodatabase, the geometry storage type used is determined by the GEOMETRY_STORAGE parameter setting of the configuration keyword you specify. When you create a feature class in a database, you define the spatial type of the field in the Configuration Keyword parameter in the Geodatabase Settings section of the Create Feature Class tool.