You can store numbers in one of four numeric data types:
- Short integers
- Long integers
- Single-precision floating point numbers, often referred to as floats
- Double-precision floating point numbers, commonly called doubles
In choosing the data type, first consider the need for whole numbers versus fractional numbers. If you just 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.
Secondly, when choosing between a short or long integer, or between a float or double, choose the data type that takes up the least storage space required. This will not only minimize the amount of storage required but will also improve 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.4E-38 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 personal geodatabases. Ranges differ slightly in ArcSDE 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 |
| Single-precision floating-point number (float) |
Approximately -3.4E38 to 1.2E38 |
4 |
Numeric values with fractional values within specific range |
| Double-precision floating-point number (double) |
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 personal geodatabase, you need only specify the data type. If you're specifying numeric fields for an ArcSDE geodatabase, you additionally specify the precision, which is the maximum length of the field, and scale, which is 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 would 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 would let you enter the 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 for ArcSDE geodatabases.
| Data type |
Precision (field length) |
Scale (decimal places) |
|---|
| Short integer* |
1–4 (Oracle)
1–5 (SQL Server, PostgreSQL)
5 (DB2, Informix) |
0
|
| Long integer |
5–10 (Oracle)
6-10 (PostgreSQL)
6-9 (DB2, Informix, and SQL Server) |
0 |
| Float |
1–6 |
1–6 |
| Double |
7+ |
0+ |
*The precision for short integers differs depending on the DBMS. Short integers with a precision of 4 in Oracle can store values up to 9,999. Short integers with a precision of 5 in SQL Server, DB2, and Informix can store values up to 32,767. There is no reason for you to specify a precision for short integers in ArcCatalog on any database except Oracle. There is no reason to specify a precision for long integers in ArcCatalog on SQL Server or PostgreSQL databases.
The following provides examples of number ranges and how you could store them in an ArcSDE geodatabase:
| Range |
Data type |
Precision (field length) |
Scale (decimal places) |
|---|
| 0 to 99 |
Short integer |
2 |
0 |
| -99 to 99* |
Short integer |
3 |
0 |
| 0 to 99,999 |
Long integer |
5 |
0 |
| -99,999 to 99,999* |
Long integer |
6 |
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 file, personal, and ArcSDE 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 and personal geodatabases can store precisely numbers that contain up to 6 digits only. For example, you could not 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 or personal 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 could store it in a double field. Float fields in ArcSDE geodatabases do not let you enter more digits than the precision for the field, so no rounding takes place.
A text field represents a series of alphanumeric symbols. This can include street names, attribute properties, or other textual descriptions. An alternative to using repeating textual attributes 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 ArcMap or ArcCatalog.
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.
Learn more about Unicode character encoding.
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, they will be converted to this format.
A BLOB is simply some data stored in the geodatabase 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.
The ObjectID 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 will usually see the ObjectID 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 Desktop functionality, such as using the identify tool, requires the ObjectID to be unique. Therefore, caution should be used when working directly with the database so that ObjectIDs are not duplicated. For example, when creating views with a one-to-many relationship, there is the possibility that ObjectIDs will be duplicated. This will cause inconsistent behavior in ArcGIS Desktop functionality.
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 feature in ArcCatalog by right-clicking it and clicking Add Global IDs. The geodatabase will then maintain these values automatically. You can create the GUID field in ArcCatalog, but you must maintain its values.
Databases with a native GUID data type, such as personal geodatabases and ArcSDE geodatabases in Microsoft 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
- The Add Global ID command can be used with ArcSDE, personal and file geodatabase data. In ArcSDE, the data may be either versioned or non-versioned.
- GUID fields can be added using the Fields tab in ArcCatalog Properties or the Add Field command in the table window.
- The Add Global ID command is available for stand-alone feature classes, tables, and attributed relationship classes. It cannot be executed on individual datasets in a feature dataset. It can only be run on the entire feature dataset.
- If a Global ID already exists, the command leaves the old column; it doesn't drop and add a new Global ID column.
- If you add a feature class to a feature dataset and want to add a Global ID column to it, you need to run the Add Global ID command on the feature dataset. This will add a Global ID column to the new feature class and any feature classes that don't already have a Global ID column. Feature classes already with a Global ID column will remain unchanged.
- Copy and paste, data extraction, and XML workspace export and import preserve Global ID values in the output geodatabase. Other data export and import methods do not preserve these values.
Unlike a hyperlink that simply links a feature's field to an image, a field of type raster can actually store the raster data within or alongside the geodatabase. To learn more, see
Raster datasets as attributes.
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 usually called SHAPE.
Geometry is the data type used by ArcGIS. If you store your data in an ArcSDE geodatabase, how geometric data is stored in the DBMS depends on the DBMS type you are using. This is because ArcSDE for each supported DBMS uses specific geometry storage types.
For example, if you choose Polygon Features for a new feature class,
the SHAPE field added by default will have a data type of Geometry. In the Field Properties section of the New Feature Class dialog box, you will see the Geometry Type 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.
For the DBMSs used with ArcSDE, how the value of the SHAPE field is stored in the DBMS depends on the geometry storage type used by the DBMS. So, if you create a new feature class in an ArcSDE Personal geodatabase, the values of the SHAPE field will be stored in the geometry storage type ArcSDE Compressed Binary.
See how ArcGIS data types compare to DBMS data types.
Learn more about geometry storage types in the DBMS.
