Is it true that modern recommendations for table design suggest usage of UUID instead of sequences for security reasons?

I should be able to use this uniqueness in many apps.

Note this only works if you have control over every SQL Server to install ranges!!

An alternative to GUIDs is to use int/bigint with ranges on each server in a distrobuted environment. A word of warning here though, identities do not work, they always take max(id)+1, you have to write a sequence solution or use sequences in SQL Server 2012. I tried using identities and the first time you sych the data between 2 servers the identies start to clash, or you range constraints raise errors.

The solution I used on SQL Server 2008 was as follows:

1. create a table to hold your sequences {name, currentValue, MaxValue, Increment}

For each PK configure a named sequence (note current value should be initialised to the min of the range or if data exists the table max +1 within the range) The name of the sequence is just the pk name, I found that the easiest way and most meaningful.

I then create a stored procedure with the following signature

GetNextSequenceValue @sequenceName varchar(128), @value int OUT

In the SP I simply do a lock for update select to get the currect value of the named sequence + 1, check if it is in range, update the sequnce table and set the out value.

I also created a scalar function

GetCurrentSequenceValue( @sequenceName varchar(128))

This simply gives you the current value of a named sequence

I then had to set the default value of the int PK columns in the table to 0 as we will never use a value of 0, it is just a flag to the trigger to get get the next sequence value.

Then I added an instead of insert trigger to the table, where if the PK value is 0 I get the next sequence value using the SP and then do the real insert. This means that if the PK is not defined in the initial insert, the sequence value is used, if it is defined, the defined value is used, this allows sync to write the PK ids.

Note: no range constraints can be used on the tables, this will cause sync from other ranges to fail, the SP must control the range using the definition from the sequence table.

This solves all issues with guids and integers, except when you have no control over the sql servers are in your system, and configuring the ranges is not posible.

I suggest ranges as follows:

Central server: -2147483647 to -1 (use all negative values gives you the same range as a positive integer)

Client servers:
First Client: 1 to 99999999
Second Client 100000001 to 199999999
…
Last client 9900000001 to 2147483647

You can always use negatives on clients if the central server makes more sense to have positive IDs.

Also, regarding the Integers disadvantage:
If a 32 bit singed Integer is to small, you can easily use a 64-bit integer instead. If you have a 64-bit system, there won’t be any performance issues. It will still be faster than guid/uuid, as they only need 8 bit in on this disk (and thus when beign read or written).but it’s much harder to run out of numbers than with 32-bit (9,223,372,036,854,775,807 – when it is singed).

Authentication – Consider GUID
Other Tables – Lean toward Integer (TINYINT / SMALLINT / INT / BIGINT as needed).

Sure you can, but it’s better with long to get the most value because a guid uses 16 bytes:

byte[] gb = Guid.NewGuid().ToByteArray();

int i = BitConverter.ToInt32(gb,0);

long l = BitConverter.ToInt64(gb,0);

.

Yes, I will have a new post out soon.

You can view the English translation here:
http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fcommunity.ugiss.org%2Fblogs%2Fdmauri%2Farchive%2F2008%2F59%2F23%2Futilizzo-di-guid-pro-e-contro.aspx&sl=it&tl=en&swap=1

I changed the GUID table to use NEWSEQUENCIALID rather than NEWID.

I am seeing similar difference in the insertions (note that Sprecher is a little faster than the machine they used. )
INT 12ms
GUID 23ms
Still the ratio is about 2 to 1 on many sequential inserts.

The clustering is less problematic by far:

table_name index_id index_type_desc index_depth avg_fragmentation_in_percent page_count
TestGuid 1 CLUSTERED INDEX 2 14.8148148148148 27
TestGuid 2 NONCLUSTERED INDEX 2 33.3333333333333 9
TestInt 1 CLUSTERED INDEX 2 9.52380952380952 21
TestInt 2 NONCLUSTERED INDEX 2 33.3333333333333 3

The 300% increase is troubling, but not nearly so troubling as the 1000% increase of the original article.

Similarly the space usage is not as dire:
index_name type_desc space_used_in_kb
PK__TestGuid__3213E83F59063A47 CLUSTERED 216.0
PK__TestInt__3213E83F5DCAEF64 CLUSTERED 168.0
uix__TestInt__fk NONCLUSTERED 24.0
uix__TestGuid__fk NONCLUSTERED 72.0

While he was getting 2 to 1 cluster and 4 to 1 not clustered, my numbers are more like plus 30% and 3 to 1. So space is an issue, but performance is likely not.

In addition I created a set of single row selects from both tables. The set included every row value (I created 2048 rows in both tables). The results are:
INT 29ms
GUID 52ms
As we see the performance is not quite 2 to one, but remember that this represents 2048 individual selects. The performance difference per select would be difficult to measure.

The result is that though there is a difference it is not particularly dire for my use case. Perhaps for yours it is. As with most things it depends on what you plan to do with it.

Pat O

Joins are no easier using ints

As for insertion order, you can create sequential GUIDS

See above about why using the primary key as a Customer code is a terrible idea.

Here’s one real question you should ask when deciding on GUIDS: Will I want to transfer the data in this record, back and forth to other systems? If so, GUIDS are great because you can insert the row into the other system without changing the key or worrying about sending a BigInt to a system with INT as the PK. You don’t even need to see if the other system has a duplicate key when inserting because unlike identity seeds, GUIDs are unique across all tables and systems.

The time I would not consider a GUID is when I have local lookup tables that are never intended to be exported.

As the MAC address is unique, no 2 servers will create the same GUID and as no 2 GUIDS can be created in the same clock tick, No 2 guids can be created on the same server. Even if you set the internal clock back, the added randomization, coupled with the clock tick, a disk id etc, the chances of creating the exact same id in the same clock tick is effectively impossible.

As for their format, they are nothing more than a collection of 8 & 16 byte ints, as if it were a 16 byte BigInt with groups of its bits populated from different sources.

If you’d bothered to read the rest of the thread what you just wrote was already covered.

Yes, random GUIDs are bad. However sequential ones are not, and are only double the side of int64. Thus there is very little negative effect in using them. Either use newsequentialid or create your own function that does the same and you’re golden.

Relation database engines are NOT optimized to work with indexes on columns whose value is assigned a random value upon insertion (such as with a GUID, or any other alphanumeric string) – this is known as an ‘unnatural progression’.

If you are implementing a solution that uses a relational database engine to store your data, whenever you are choosing a data type for either an index column or for a table’s primary key ALWAYS choose an integer (of the appropriate size).

Choosing a GUID or some other alphanumeric data type for an index column or for a primary key is now and has always been a rookie’s mistake.