obsidian wrote:if you're reading the initial post, it seems to be a sort of test or quiz content management system it's being used for. with that in mind, the likelihood that you're going to have more than one user with adminstrative priviledges hitting the database to update a test at the exact same instant is slim to none. obviously, if you're using a larger application (such as a forum, image gallery, message board, etc) where all of your users are inserting into the same tables at the same time, you'd want to do something a little more restrictive.
OK. What does it cost to do it "the right way?" Nothing. What do you gain doing it "the wrong way?" A possibility for failure. and a failure that may be hard to trace down and fix in the future.
Now, if you're importing data, and you know you're the only person in the database, sure, use select max(id) for stuff. That's fine.
But once you release an app to the users, you should have race conditions removed as much as you can. And leaving it in is just lazy and sloppy.
Now, if it were really hard to implement, or slow, or some other issue, there might be a reason for using select max(). But it's not.
The first thing I found out when I started programming is that users NEVER use the application the way you think they will. My very first app was a simple little "one user" database written in BASIC on a burroughs B-28 cluster system in 1985 or so. By 1987 it was in use at every school at every air force base by every instructor. Trust me, I found TONS of problems in it real fast. 🙂 So now, I don't do things like selecting max() or not flocking a file cause "no one else will be using it". Someone else WILL eventually use it that way, and it's just so much easier to not chase this stuff down once it's in production.
