Auto increment is a terrible idea

Re:Auto increment is a terrible idea by davweb on Thursday November 30, 2017 @08:42AM (#15815596)

If you're doing manual updates to a production DB, using START TRANSACTION and then checking the outcome of your changes before you use COMMIT stops typos becoming catastrophes.

[ Parent | on HN ]

Re:Auto increment is a terrible idea by j_s on Thursday November 30, 2017 @10:21AM (#15816393)

In case it's not obvious: new auto increment IDs are skipped forever whenever a transaction is rolled back.

This isn't really an issue at all but can upset those with OCD-ish tendencies.

[ Parent | on HN ]

Re:Auto increment is a terrible idea by corobo on Thursday November 30, 2017 @11:58AM (#15817264)

those with OCD-ish tendencies best hope they never lose any customers then.

[ Parent | on HN ]

Re:Auto increment is a terrible idea by btschaegg on Thursday November 30, 2017 @02:22PM (#15818673)

This. There's so much in software development that relies on guarantees that can only be upheld by behavior like this that I _sincerely_ doubt that anyone having issues with skipped rows is in the right place.

There are arguments for and against any technique, but this one seems really ridiculous to me, especially if you consider what any "countermeasure" would do to the code (which is usually much more important than the data in the long run!).

[ Parent | on HN ]

Re:Auto increment is a terrible idea by j_s on Thursday November 30, 2017 @01:14PM (#15818033)

UPDATE tbl SET deleted=1

[ Parent | on HN ]

Re:Auto increment is a terrible idea by neoeldex on Thursday November 30, 2017 @09:16AM (#15815807)

There's some caveats with this approach, since your DB has to keep track of the split state since you've started the transaction, it's quite a lot busier. So don't keep transactions open for any long stretches of time ;)

[ Parent | on HN ]