防止两个用户编辑相同的数据
我在不同的 Web 应用程序中看到了一个功能，包括 Wordpress（不确定？），如果用户打开数据库中的文章/帖子/页面/其他内容，而其他人正在同时编辑相同的数据，则会向用户发出警告。
我想在我自己的应用程序中实现相同的功能，并且我对此进行了一些思考。以下示例是如何执行此操作的良好实践吗？
事情大概是这样的：
1) 用户 A 进入神秘文章 X 的编辑页面。查询数据库表Events以确保没有其他人目前正在编辑同一页面，但那时已经没有人了。然后随机生成一个令牌，并将其插入名为 Events 的数据库表中。
1) 用户 B 也希望对文章 X 进行更新。现在，由于我们的用户 A 已经在编辑该文章，因此 Events 表为查询后看起来像这样：
| timestamp | owner | Origin | token |
------------------------------------------------------------
| 1273226321 | User A | article-x | uniqueid## |
2) 正在检查时间戳。如果它有效并且不到 100 秒，则会出现一条消息，并且用户无法对请求的文章进行任何更改 X：
Warning: User A is currently working with this article. In the meantime, editing cannot be done. Please do something else with your life.
3) 如果用户 A 决定继续并保存其更改，则令牌将与所有其他数据一起发布更新数据库，并切换查询以删除带有标记 uniqueid## 的行。如果他决定做其他事情而不是提交更改，用户 B 文章 X 仍可在 100 秒内进行编辑。
请告诉我您对此方法的看法！
祝大家周末愉快！
I have seen a feature in different web applications including Wordpress (not sure?) that warns a user if he/she opens an article/post/page/whatever from the database, while someone else is editing the same data simultaneously.
I would like to implement the same feature in my own application and I have given this a bit of thought. Is the following example a good practice on how to do this?
It goes a little something like this:
1) User A enters a the editing page for the mysterious article X. The database tableEvents is queried to make sure that no one else is editing the same page for the moment, which no one is by then. A token is then randomly being generated and is inserted into a database table called Events.
1) User B also want's to make updates to the article X. Now since our User A already is editing the article, the Events table is queried and looks like this:
| timestamp | owner | Origin | token |
------------------------------------------------------------
| 1273226321 | User A | article-x | uniqueid## |
2) The timestamp is being checked. If it's valid and less than say 100 seconds old, a message appears and the user cannot make any changes to the requested article X:
Warning: User A is currently working with this article. In the meantime, editing cannot be done. Please do something else with your life.
3) If User A decides to go on and save his changes, the token is posted along with all other data to update the database, and toggles a query to delete the row with token uniqueid##. If he decides to do something else instead of committing his changes, the article X will still be available for editing in 100 seconds for User B
Let me know what you think about this approach!
Wish everyone a great weekend!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我创建了另一种方法，您应该添加一个列（正在编辑），假设用户（A）想要编辑文章X，所以当他按下（编辑）按钮时，列（正在编辑）=True，当他完成编辑时列（正在编辑）= False，因此当用户（B）按下编辑按钮编辑同一篇文章（X）时，您应该检查（正在编辑）是否为真或假，如果为真则（弹出消息，文章为正在由（用户 X）编辑。
我认为这将是一个完美的方法。
I created another approach where you should add a column(is editing), let's say user(A) want to edit the article X, so when he press (Edit) button the column(is editing)=True and when he finishes the editing the column(is editing)= False, so when user(B) press edit button to edit the same article(X) you should check if (is editing) true or false, if it's true then (Msg pop up, the article is under editing by (User X).
I think this would be a perfect approach.
是的，这很好，应该可以正常工作。
此外，我还添加了用户 B 打破锁定的可能性 - 如果需要的话！
也就是说，可以用 B 的锁替换 A 的锁。这样，您就可以避免时间限制，他们会看到“嘿，这正在由 A 编辑，并且此锁已存在 XXX 秒/分钟”。你想打破这把锁吗？
对于好的用户（即没有恶意管理员），这种方法可能比只花 100 秒编辑某些内容更好 - 有时您只是需要更多时间。
Yeah, that's great and should work fine.
In addition, I'd add the possibility for user B to break the lock - if that's at all wanted!
That is, the possibility to replace A's lock by B's. This way, you could avoid the time restraint, and they would see 'Hey, this is being edited by A, and this lock is XXX seconds/minutes old. Do you want to break this lock?'.
With nice users (i.e. no malicious admins), this approach may be better than having just 100 seconds to edit something - sometimes you just need more time.
听起来效果会很好。如果您想对其进行非规范化并删除额外的
Events表，只需将UserId和Timestamp字段添加到Articles即可> 表，因为这就是您真正需要的。您可以轻松检查
UserId是否不匹配，以及Timestamp是否小于 100 秒，然后显示消息。这样，您就不必在单独的表上执行任何删除操作。
Sounds like it will work fine. If you want to denormalize this and remove the extra
Eventstable, just add aUserIdandTimestampfield to theArticlestable, as that is all you really need.You can easily check if the
UserIddoesn't match and if theTimestampis less than 100 seconds old, then show the message.This way, you won't have to do any deletions on a separate table.
我只是补充一点，如果页面上执行了某些操作来更新时间戳，那么您可以每分钟左右触发一次 AJAX 查询。
I'd just add that you could have an AJAX query fire every minute or so if something has been done on the page to update the timestamp.
编辑一篇文章总是需要不到 100 秒吗？
Does editing an article always take less than 100 seconds ?