views:

23

answers:

2

Consider the following sample table in MySQL:

CREATE TABLE transactions 
(
    transId BIGINT NOT NULL AUTO_INCREMENT,
    transDate  DATETIME NOT NULL,
    transTotal  DECIMAL(10,2),
    PRIMARY KEY (transId)
);

This table is used in high volume operations i.e. lots of INSERTS. You will eventually reach the maximum limit of transId. (Of course in reality BIGINT offers pretty much larger range.)

What are the possible strategies to prevent this and not worry about roll-over issues that would break your application.

  • Would UUID as primary be the solution?
+2  A: 

Unsigned bigint is limited by 18446744073709551615. Assuming you have 10 000 000 000 inserts per day - you will reach that limit only within 59 years

zerkms
In all fairness, it's not unsigned, so it'll only take 30 years, if you had a supercomputer capable of 10 billion rows a day.
Mike Sherov
@Mike Sherov: so sad... **only 30 years**... ;-)
zerkms
+1 So many people who ask this question don't do the math.
Bill Karwin
Maybe in 30 years, MySQL will support 128 bit integers, that'll buy you enough time till the end of the known universe.
Mike Sherov
@Mike Sherov: if no - after 30 year he will come here and we will teach him how to change it to `unsigned`...
zerkms
All these "30 years" commenters would be well advised to study their counterparts in the 70s and 80s dismissing concerns about using two digit years in date fields. That said, it drives me nuts when people fail to specify 'unsigned' for sequence generated IDs
coolgeek
A: 

What are the possible strategies to prevent this and not worry about roll-over issues that would break your application.

Sell your application for a couple of billion dollar and you don't have to worry about anything.

Frank Heikens