Avoiding duplication of IDs in php [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 10 years ago.

I have a php browser based application that is for a hospital management system. The situation is that there are 3 departments from which payments are made ie. reception, lab and pharmacy. The worker at each location above is different and so is their input. Each of these departments sends a receipt information to one single table called receipts and hence an ID is generated which is the next ID after the last ID of the table. The data is sent back to the same department based on this ID (that was generated based on the last ID from the table).

Now the problem occurs when two departments click the submit button at the same time. Both these people get the same ID since at that time the last ID is the same for both queries. This will cause problems for storing and sending back data to the department.

Now is there a solution for this? I was told triggers would solve it but I don't want to go there and keep it simple. I thought of random ID generation but the hospital guys want continuous ID as it will appear on the receipt. Also take into account that the system should not slow down (considerably).

EDIT: Whoops seems like there is a lot more info here hence Autoincrement is not working. There are 3 columns to consider ie. id(Pkey), receiptno and debitno. Now if the person pays at the same time then the id and receiptno will be increased by one together and debitno will be empty. But if he is going to pay later then his receiptno is going to be NULL while his ID and debitno w开发者_JS百科ill increase by one from the last ID entered. Therefore it is not necessary that the receiptno (that is going to be sent back to the department person) will be filled and hence auto increment would not work then correct? Thanks guys again for your solutions esp autoincrement.

---

Use an AUTO_INCREMENT (MySQL) field for the ID column so the database takes care of unique ID generation. Other database systems have similar fields, e.g. the serial field type in PostgreSQL.

---

I read the update to your question, and you should really break up that database. Just so I understand - you need to create a new order with a unique ID. But the order might not be paid straight away, so when the order is paid, that also needs a unique receipt number. You could generate a random number for receipt, make the field unique, and while-no-error update the field in the database. This is terribly yucky.

You'd be better off creating a new table for payments. So your orders table would store an autoincremented orderID (as per TheifMasters answer), and the other data like userID, customerID, date, description etc. Then you'd have a payments/transactions table, which would store the paymentID (autoincremented), orderID (which relates back to the orders table), payment date, status, amount etc etc.

This is the preferred method of tracking payment transactions. Now that you know where to start, you should definitely do some research on how to actually implement this. We use relational databases for a reason!