What’s In An ID? Global IDs vs. Object IDs
By Jerry Swanson
A major role of a GIS professional is data management. This can include external data sources such as Excel spreadsheets, survey data, and even pictures with a geotag. The most common data GIS professionals use is located in a geodatabase, including file geodatabase or databases stored in a Spatial Database Engine (SDE). Managing large databases, especially at a city or county level, such as parcels, address points, or street centerlines, can present numerous challenges to the database administrator.
Object IDs
Luckily for Data Managers, software and relational database management systems (RDBMS) provide built in functions to assist with data management. One of the main functions is to provide a unique ID for each record within a database. In GIS, specifically Esri’s software suite, this unique ID is known as an ObjectID. ObjectIDs are a 32-bit integer, non-zero, positive only, and generally sequential numeric value. ObjectIDs can be useful in many way including as a unique identifier for a particular feature, assist in the creation of additional unique ID’s via python scripts, and typically providing information on when a particular record was created based on the value alone. The field is a requirement in Esri’s software, from shapefile to a SQL based enterprise database. End users cannot edit ObjectIDs and the values are auto generated as a function of the software.
While ObjectIDs can be helpful in certain cases, they can also cause issues in data management. The main flaw in using ObjectIDs as a unique identifier, is that they do not stay constant throughout the lifetime of a particular feature class. For example, if you have been editing an address point layer over time including adding and deleting records, the sequence of the ObjectIDs will get out of sync. This causes a problem if you decided to export/import that feature class, as the ObjectIDs will be reset during the process. This means that if there was any relationship classes or joins performed on the ObjectID field, the link would be lost with the new feature class. This is why Esri and GIS professionals recommend not using the ObjectID for linkage purposes. Any GIS database manager who has experienced working with ObjectID’s in this capacity will tell you it’s a data nightmare. There is a work around for using the ObjectID as a unique identifier which includes making a copy of the ObjectID field before moving the data, but Esri provides an additional unique ID for better data management, GlobalIDs.
Global IDs
GlobalIDs are similar to ObjectIDs in the sense that they cannot be edited by the end user, the IDs are generated automatically by the software, and they provide a unique identifier for a particular feature. GlobalID’s are a 128-bit string, which provide sufficient combinations within a database and cannot be duplicated since the ID’s are controlled by Esri. The main difference between ObjectIDs and GlobalIDs is the ability to retain their value throughout the lifespan of the feature class. This makes GlobalIDs the ideal unique identifier for a variety of operations within GIS. Examples of use include being the key identifier in relationship classes and related tables and disconnected editing work flows. In some cases, GlobalID’s are required for use specifically in the case of enabling attachments in a feature service for use in ArcGIS Online and Collector for ArcGIS. GlobalID’s can easily be generated using the “Add Global IDs” tool in ArcGIS Desktop or in ArcCatalog by right clicking on the feature dataset or a particular feature class and clicking “Enable Global IDs.”
Conclusion
Depending of the needs of the organization, GIS professionals may utilize ObjectIDs or GlobalIDs based on work flow, database management protocol, and standard operation procedures. Both types of IDs provide different levels of value and function and the discussion points described above should be considered to ensure one aspect of successful data management in GIS.
