GUID vs INT
Francisco J. Carabez
V1.0 Feb 25 2014
Has better performance when used in joins, indexes and conditions.
Numeric values are easier to understand for application’s users if
they are displayed.
Widely used for incrementing key values serially.
Less space for storing.
Unique across the [universe] servers.
Client side generated. With GUID, the client application can
generate a new value and can send it to the server. It does not need
to wait till the SAVE function returns to know what is the ID.
Consolidation and syncronization. You have Customer Table in 5
different Databases and you want to make a Data warehouse – no
problem – the records can keep their keys.
A GUID is most commonly showed as text as a sequence of
hexadecimal digits separated into five groups, such as:
This text notation contains the following fields, separated by hyphens:
Hex digits Description
4 Initial two bytes from Data4
12 Remaining six bytes from Data4
INT, BIGINT & GUID
INT (4 bytes or 32bits)
++Native and faster to manage in older Pcs.
++Less space for Indexing.
BIGINT (8 bytes or 64bits)
++Native and faster to manage in new Pcs.
+Moderate space for Indexing.
GUID (16 bytes or 128bits)
+Practical without performance hits on new Pcs.
-Fragmentation hits on Indexing.
-More space for storing.
Cast BIGINT as GUID8
THE BETTER OF BOTH WORLD
Practical unique for most database systems, meaning easier
integration with replication
Semi-random client side or server side generated.
Semi-Sequential based on date-time stamp.
Not Fragmentation hits on indexes.
LOW INT (lower 4 bytes)
Hold seconds elapsed since Jan 1, 2000.
HI INT (upper 4 bytes)
Date-time stamp RANGE?
One Year has 31536000 Seconds (365*24*60*60)
Lower INT can hold 4294967295
4294967295 / 31536000 = 136 years
The GUID8 time stamp approach is safe from YEAR
Probability of one DUPLICATE?
Lower INT hold the Date-Time stamp in seconds.
For every second, the upper INT can hold a
RANDOM Number in range from 0 to 4,294,967,295
So having a duplicate is possible but far probable.
ON DATABASE MANAGEMENT
GUID is hard to read or typing... Yes but come on! if you're querying that much at
once, you're probably doing it wrong anyhow.
No all tables needs a GUID.
Cost of storage are cheaper and computers are fasters.
GUID Allows asynchronous architectures more easily.
GUID guiltless used by: IPv6, Electronics Devices, Item tagging, OS…
GENERATION CODE SQL
( EXTRACT(DAY FROM now()-'2001-01-01')*(24*60*60) ) +
( EXTRACT(HOUR FROM now()) * (60*60) ) +
( EXTRACT(MINUTE FROM now()) * (60) ) +
EXTRACT(SECOND FROM now())
AS BIGINT ) << 32
CAST ( CAST( ROUND(RANDOM()*999999999) AS INT) AS BIGINT )
AS BIGINT )
Download this presentation: