避免php中ID重复
我有一个基于 php 浏览器的应用程序，用于医院管理系统。情况是有 3 个部门进行付款，即：接待处、实验室和药房。上述每个地点的工人都是不同的，他们的投入也是不同的。每个部门都会将收据信息发送到一个称为收据的表，因此会生成一个 ID，该 ID 是该表的最后一个 ID 之后的下一个 ID。数据将根据此 ID（根据表中最后一个 ID 生成）发送回同一部门。
现在当两个部门同时点击提交按钮时就会出现问题。这两个人都获得相同的 ID，因为此时两个查询的最后一个 ID 是相同的。这将导致存储数据和将数据发送回部门时出现问题。
现在这个问题有解决办法吗？有人告诉我触发器可以解决这个问题，但我不想去那里并保持简单。我想过随机生成 ID，但医院人员想要连续的 ID，因为它会出现在收据上。 还要考虑到系统不应减慢（相当大）。
编辑：哎哟，这里似乎有更多信息，因此自动增量不起作用。 有 3 列需要考虑，即。 id(Pkey)、收据号和借记号。 现在，如果该人同时付款，则 id 和receiptno 将一起加一，debitno 将为空。但如果他稍后付款，那么他的收据编号将为 NULL，而他的 ID 和借记编号将从最后输入的 ID 开始增加 1。 因此，没有必要填写收据号（将被发送回部门人员），因此自动增量将不起作用，那么正确吗？ 再次感谢大家提供的解决方案，特别是自动增量。
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 will 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对 ID 列使用
AUTO_INCRMENT(MySQL) 字段，以便数据库负责生成唯一 ID。其他数据库系统也有类似的字段，例如PostgreSQL中的serial字段类型。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. theserialfield type in PostgreSQL.我阅读了您问题的更新，您确实应该分解该数据库。据我了解，您需要创建一个具有唯一 ID 的新订单。但订单可能不会立即支付，所以当订单支付时，也需要一个唯一的收据号码。您可以生成一个随机数用于收据，使该字段唯一，并在无错误的情况下更新数据库中的字段。这真是太恶心了。
您最好创建一个新的付款表。因此，您的订单表将存储一个自动增量的 orderID（根据 TheifMasters 的答案），以及其他数据，如用户 ID、客户 ID、日期、描述等。然后您将有一个付款/交易表，它将存储 paymentID（自动增量）， orderID（与订单表相关）、付款日期、状态、金额等。
这是跟踪付款交易的首选方法。既然您知道从哪里开始，那么您肯定应该对如何实际实现这一点进行一些研究。我们使用关系数据库是有原因的！
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!