As we know, In Sql Server, The IDENTITY (n,m)
means that the values will start from n
, and the increment value is m
, but I noticed that all database designers make Identity columns as IDENTITY(1,1)
, without taking advantage of all values of int data type which are from (-2,147,483,648) to (2,147,483,647)
,
I am planning to make all Identity columns as IDENTITY (-2,147,483,648, 1)
, (the identity columns are hidden from the application user).
Is that a good idea ?
Advertisement
Answer
If you find that 2billion values isn’t enough, you’re going to find out that 4billion isn’t enough either (needing more than twice as many of anything over the lifetime of a project, than it was first designed for, is hardly rare*), so you need to take a different approach entirely (possibly long values, possibly something totally different).
Otherwise you’re just being strange and unreadable for no gain.
Also, who doesn’t have a database where they know that e.g. item 312 is the one with some nice characteristics for testing particular things? I know I have some arbitrary ids burned in my head. They may call it “so good they named it twice”, but I’ll always know New York as “city 657, covers most of our test cases”. It’s only a shorthand, but -2147482991 wouldn’t be as handy.
*To add a bit to that. With some things you might say “ah about 100” and find it’s actually 110, okay. With others you’ll find actually it’s actually 100,000 – you were out by orders of magnitude. The higher the number, the more often the mistake is of this sort due to the sort of problems that end up with estimates in the billions being different to those that end up with answers in the dozens. If you estimate 200 is your max in a given case, you should probably leave room for maybe a few hundred more. If you estimate 2billion in a given case, you should probably leave room for a few quadrillion more. That said, the only time I saw someone actually start an id at minus 2billion they ended up having about 3,000 rows.