你能保证mysql中唯一的序列号吗
因此,我们正在处理信用卡付款,每笔付款都需要一个唯一的参考 ID。我们正在使用MySQL。
有一个付款
表,其中有一个自动递增的主键id、processing_date、created_at、updated_at。我的问题是,此记录无法保留到付款处理完成后(由于应用程序工作流程,此过程无法更改)。因此,我们不能简单地使用主键,因为只有在处理付款之后它才会存在,并且此后添加了具有唯一约束的 reference_id
列。
我的问题是,是否有一种可靠的方法可以根据现有的表列(即使用诸如 MAX(reference_id) + 1 之类的东西)生成连续(或接近)数字,处理付款(使用curl),然后将付款记录插入到带有之前生成的 reference_id
的表中,同时确保唯一性。本质上是在数据库中保留之前生成的reference_id。
So, we're processing credit card payments, and each payment needs a unique reference ID. We are using MySQL.
There is a payments
table which has an auto incrementing primary key id, processing_date, created_at, updated_at. My issue is that this record cannot be persisted until after the payment has been processed (this process cannot be changed due the applications workflow). Due to this we cannot simply use the primary key as it would not exist until after the payment has been processed and have since added a reference_id
column with a unique constraint.
My question is, is there a reliable method of generating a sequential (or close to) number based on an existing table column (i.e. using something like MAX(reference_id) + 1
), processing the payment (using curl) then inserting the payment record into the table with the previously generated reference_id
whilst ensuring uniqueness. Essentially reserving the previously generated reference_id with the database.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
不要尝试将其建立在现有专栏的基础上。如果您同时进行 2 笔交易,则最终可能会出现 2 笔具有相同 ID 的交易。
基于 UUID 或时间戳。
我有一个类似的系统,交易ID是MMDDYYHHMMSS + 8位随机数。这对于小批量交易来说是没问题的,并且 1 秒内不太可能出现 2 个或更多重复交易。
许多网关都使用相同的方案。
UUID 是最安全的,因为它保证它是全球唯一的。
Don't try to base it off an existing column. If you get 2 transactions going at the same time you can end up with 2 transactions with the same ID.
Base it on a UUID, or a timestamp.
I have a similar system and the transaction ID is MMDDYYHHMMSS + 8 digit random number. This is okay for low volume transactions and it very unlikely there will be 2 or more duplicate transactions in 1 second.
Many gateways use this same scheme.
The UUID is the safest as it guarantees it is globally unique.
您可以在付款表中添加另一列作为状态/确认标志。当付款开始时,您插入值并将状态设置为“已开始”(或其他),这样您就可以使用自动生成的 ID。
付款完成后,您可以将标志设置为“已完成”。如果付款被拒绝,请删除该行。
为了优化这一点,您还可以创建一个每晚运行的内务处理程序,并删除超过 2 天或类似状态的“已开始”状态的行。
You could add another column to your payments table as a status / confirmed flag. When the payment starts you insert the values and set the status to "started" (or whatever) this way you can use your auto generated id.
When the payment is completed you can then set the flag to "completed". If a payment is rejected delete the row.
To optimise this you could also create a housekeeping procedure that runs every night and deletes rows with a status of "started" that are over 2 days old or something similar.
您需要一个额外的表来存储reference_id,并在每次需要新号码时更新该值。将所有内容都包含在交易中,您就可以省钱了。 MySQL 变量的使用使得 SQL 中的事情变得非常简单:
——真正的工作:
由于锁定,您不会遇到并发完整性问题,即使在回滚之后也是如此。但用户可能需要等待。
You need an extra table for the reference_id and update this value each time you need a new number. Wrap everything in a transaction and you're save. The usage of a MySQL-variable makes things very easy in SQL:
-- the real job:
Because of the lock you won't have integrity problems with concurrency, not even after a ROLLBACK. But users might have to wait.