views:

122

answers:

3

Given the table:

CREATE TABLE Table1
(
    UniqueID int IDENTITY(1,1)
    ...etc
)

Now why would you ever set the increment to something other than 1?

I can understand setting the initial seed value differently. For example if, say, you're creating one database table per month of data (e.g. Table1_082009, Table1_092009) and want to start the UniqueID of the new table where the old one left off. (I probably wouldn't use that strategy myself, but hey, I can see people doing it).

But for the increment? I can only imagine it being of any use in really odd situations, for example:

  • after the initial data is inserted, maybe later someone will want to turn identity insert on and insert new rows in the gaps, but for efficient lookup on the index will want the rows to be close to each other?
  • if you're looking up ids based directly off a URL, and want to make it harder for people to arbitrarily access the other items (for example, instead of the user being able to work out that changing the URL suffix from /GetData?id=1000 to /GetData?id=1001, you set an increment of 437 so that the next url is actually /GetData?id=1437)? Of course if this is your "security" then you're probably already in trouble...

I can't think of anything else. Has anyone used an increment that wasn't 1, and why? I'm really just curious.

+4  A: 

One idea might be using this to facilitate partitionnement of data (though there might be more "automated" ways to do that) :

  • Considering you have two servers :
    • On one server, you start at 1 and increment by 2
    • On the other server, you start at 2 and increment by 2.
  • Then, from your application, your send half inserts to one server, and the other half to the second server
    • some kind of software load-balancing

This way, you still have the ability to identify your entries : the "UniqueID" is still unique, even if the data is split on two servers / tables.

But that's only a wild idea -- there are probably some other uses to that...

Pascal MARTIN
+1, that's not a bad idea. I was about to say that though I agree there are maybe more automated ways to do that kind of thing, the IDENTITY specifier has probably been around since the dark old days of the SQL standard when we had no such tools... but Wikipedia tells me that identity columns were only introduced in SQL:2003. Go figure.
Gavin Schultz-Ohkubo
Standardised in SQL 2003, sure, but I think most DBMSes have had them since long before that. Pretty sure SQL Server supported IDENTITY with custom increments in 7.0 (which was released in '98, I think?), probably earlier.
Cowan
+2  A: 
Raj More
You just blew my mind. I can see a use for the negative increment though: an identity(1000000,-1) countdown "timer" which, when the value reaches 0, causes a trigger to truncate the table. A practical joke for your last day at work. You could do the same counting up of course, but it's not quite as delicious to watch approaching...
Gavin Schultz-Ohkubo
@Gavin Schultz: You are pure evil mate. I hope you don't do this on any meaningful table.
Raj More
A: 

Only for entertainment. And you have to be REALLY bored.

onupdatecascade