OK we have a custom ticketing system developed in PHP/PostgreSQL.
How it works now is that information is entered, click submit, ticket number is shown.
What They would like, Ticket number shown, enter information, click submit.
Now I know I can just create a blank record and use that record id then do an update when the user submits.
I wanted to know if there would be a better/alternative way in doing this?
Some key points:
- record id is the pk, auto increments
- record id’s must be in order, no skipping record id numbers
The problem is a end user could start the ticket id process and not click submit which would result in a blank record. Which might be the best way to proceed.
any ideas or is this the best approach?
EDIT:
I understand all the gripes and what I need to do to complete the requested action, looks like I’m just going to be dealing with blank records. It shouldn’t happen to often but I wanted to see if anyone had to deal with this before. Thanks for the input
There is no practical way to do this.
It’s not prudent to lock the tables or use transactions as the app must wait for additional user input. That means tickets with info will have gaps between them. This is a silly requirement on the client’s part. Your managers should have done a better job explaining why getting the ticket number afterward is the way to go (race conditions):
Obtaining the next auto-increment id requires access to a resource. This means there must be control to that resource. Imagine implementing this approach at a deli. One person takes a number and decides what they want. Another person tries to grab a number. You must somehow stop them (lock tables) or your numbers might be out of order should the first person leave! That is of course a silly way to run a business. If the first person decides not to order anything, he should be able to just throw the ticket away (you’ve got over 4 billion tickets — and can even increase that — so you’ll be fine).