The thing is, such an autoincrementing integer field is typically used as the primary key, possibly in addition to the "real" primary key of the table (e.g., a unique username for a table of users). So, the main requirement is uniqueness. The expectation is that the integers be strictly increasing, but even that does not always hold true (e.g., SQLite's INTEGER PRIMARY KEY fields might reuse key values from deleted rows, unless AUTOINCREMENT is explicitly specified). It makes sense for the increment to be one rather than two since if it is strictly increasing, incrementing by two will run through the range of possible keys twice as fast, but that should not be relied upon to begin with.
cretaceous wrote:I have a site that creates order numbers using the auto incremented ID, then it makes a PDF with that number.
This pattern that the webhost has invented, would break that in terms of the PDF - no one could rely on a fixed order number.
Many situations also require consecutive order numbers - this would get broken.
Perhaps the order data should be stored in the database, sorted according to order number upon retrieval. This way, you do not need order numbers to be contiguous: they could even be random if you sort according to date/time.
cretaceous wrote:I also use a third party web service that requires consecutive query numbers - so that would get broken too.
Why can't you record the current/next query number? Besides, since they probably want this as a nonce to prevent replay attacks, I would expect that the protocol would allow you to establish a fresh session with a new number, upon which you would respond with the next number, etc.
