Identity column

An identity column is a column (also known as a field) in a database table that is made up of values generated by the database. This is much like an AutoNumber field in Microsoft Access or a sequence in Oracle. Because the concept is so important in database science, many RDBMS systems implement some type of generated key, although each has its own terminology.

An identity column differs from a primary key in that its values are managed by the server and usually cannot be modified. In many cases an identity column is used as a primary key; however, this is not always the case.

It is a common misconception that an identity column will enforce uniqueness; however, this is not the case. If you want to enforce uniqueness on the column you must include the appropriate constraint too.

In Microsoft SQL Server you have options for both the seed (starting value) and the increment. By default the seed and increment are both 1.

Code Samples

 
Create Table Contacts (
   FirstName varChar(30),
   LastName  varChar(30),
   Phone     varChar(16),
   ContactID int identity(1, 1)
)

or

Create Table Contacts (
   FirstName varChar(30),
   LastName  varChar(30),
   Phone     varChar(16)
)
GO
Alter Table Contacts Add ContactID int identity(1, 1)

It is often useful or necessary to know what identity value was generated by an INSERT command. Microsoft SQL Server provides several functions to do this: @@IDENTITY provides the last value generated on the current connection in the current scope, while IDENT_CURRENT(tablename) provides the last value generated, regardless of the connection or scope it was created on.

Example:

   Insert Into Contacts ( FirstName, LastName ) Values ( 'Test', 'User' )
   --
   Select @@Identity
   -- OR --
   Declare @ID int
   Select @ID = @@Identity
   Update Contacts Set Phone = 'XXX-YYY-ZZZZ' Where ContactID = @ID
gollark: That's not annoying. That's the point.
gollark: Obviously they have collisions generally, pigeonhole principle and all.
gollark: They're generally very hard to find in good ones.
gollark: Those who find collisions in hash functions cannot be trusted.
gollark: That is the wrong way.

See also
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.