确保两个人不在我的网络应用上编辑同一行的最佳方法是什么？
我有一个PHP / jQuery / AJAX / MySQL应用程序，用于管理数据库。 我想实现阻止多个用户同时编辑同一数据库行的function。
- 这个叫什么？
- 我是否使用令牌系统，谁拥有令牌可以编辑它，直到他们释放令牌？
- 我是否使用“上次编辑日期/时间”来比较您将HTML表单加载到数据库中的时间，如果数据库是最重新编辑的，那么它会警告您？
- 我是否使用数据库function锁定行？
我只是不确定哪个是最好的。 假设有10到15个并发用户
有两种通用方法 – 乐观和悲观锁定。
乐观锁定通常更容易在基于Web的环境中实现，因为它基本上是无状态的。 它也可以更好地扩展。 缺点是它假定您的用户通常不会尝试同时编辑同一组行。 对于大多数应用程序来说，这是一个非常合理的假设，但您必须validation您的应用程序不是用户经常踩到彼此脚趾的exception值之一。 在乐观锁定中，您将拥有某种last_modified_timestamp列，当用户获取数据时，您将SELECT ，然后在更新日期时使用WHERE子句，即
UPDATE table_name SET col1 = <>, col2 = < >, last_modified_timestamp = < > WHERE primary_key = <> AND last_modified_timestamp = <>
如果更新1行，则表示您已成功。 否则，如果它更新了0行，你知道其他人在过渡期间修改了数据，你可以采取一些行动（通常向用户显示新数据并询问他们是否要覆盖，但你可以采用其他冲突解决方法）。
特别是在基于Web的应用程序中，悲观锁定更具挑战性，特别是当用户可以在不注销的情况下关闭浏览器或用户可能开始编辑某些数据并在点击Submit前去吃午餐时。 它使得扩展更难，并且通常使应用程序更难管理。 如果用户经常尝试更新相同的行，或者如果更新行需要花费大量时间给用户，那么真的值得考虑，因此值得让他们知道其他人已锁定该行。
我打算将它实现到我自己的一个系统中。
您可以在记录数据库中创建新列，称为timelocked。
打开记录时，您可以将打开时间段的记录设置为当前时间。 在编辑记录期间，每隔2分钟通过ajax将keepalive发送回服务器。 当发送keepalive时，服务器会将时间锁定的时间增加到发送请求的当前时间，因此第四次（这将在一秒内有意义）。 用户完成编辑后，将timelocked设置为false。
现在，如果有人去打开已经打开的记录，那么php会检查 – 如果timelocked == false – 意味着它没有被编辑，
否则，可能正在编辑记录，但如果用户关闭了他们的浏览器窗口该怎么办。 这就是使用keepalive的原因。
如果当前时间和时间锁之间的差异大于2分钟，则意味着它们不再是生动的编辑，这将允许您打开它。
希望你能理解这一切。
不要试图阻止它。 让他们决定在编辑冲突的情况下该怎么做。
向表中添加时间戳。 将检索行的时间戳与当前时间戳进行比较。 让他们了解他们的负载和保存之间的变化，让他们决定采取什么行动。
所以是的，3号。
我个人不会阻止这一点。 如果这是作业的要求，我会跟踪用户当前/最后的已知位置，并禁止某人编辑其他人正在编辑的同一行。 我已经看到人们在表中添加了一行，表示isLocked或isBeingWorkedOn等…但我已经看到这种类型的系统失败得多，或者如果有人在工作时关闭它，需要审核以解锁卡住的表等。 ..
1）这称为锁定。 引用关系数据库（如MySQL）时有两种主要的锁定类型：表锁定和行锁定。 表锁定确保一次只有一个会话对表进行更改，而行锁定确保一次只有一个会话对特定行进行更改。 您可以将行锁定视为一种比表锁定更细粒度的并发访问方法。 行锁定更复杂，但允许多个并发会话写入同一个表（如果您的数据库有大量并发写入，则很重要 – 对于10-15个用户，表锁定应该没问题）
2-3）MySQL为您提供并发访问权限！ 它会在后台自动实现锁定。 锁定类型（行或表）取决于您使用的存储引擎。 例如，MyISAM使用表锁定，InnoDB使用行锁定。 MySQL使用内部表来管理它。 您可以通过检查Table_locks_immediate和Table_locks_waited变量（它使用您的选项号2）来查询此表的状态（以及数据库上的所有锁）。
当您在另一个会话使用表（或行）时发出INSERT或UPDATE语句时，调用应用程序（在本例中为PHP）将暂停几毫秒，直到另一个会话完成写入。
4）同样，MySQL将自动处理锁定，但您可以使用LOCK TABLES和UNLOCK TABLES命令手动管理表锁定。 如果您使用InnoDB进行行锁定，则可以使用许多函数来手动管理并发访问。
有关MySQL锁定系统的概述，请参阅MySQL的内部锁定页面，以及InnoDB的行锁定function的并发插入 。
正如其他人所说，处理冲突的更新要容易得多。 你所建议的是被称为pesimistic锁定。 它被称为thate，因为两个用户很可能同时尝试编辑同一条记录。
真的吗？
如果用户必须重新开始，这是一场灾难，因为他们尝试更新的数据是由其他人更改的。
锁定成本，你总是锁定一个悲观的方案，所以你有一个开销，这是在你开始查看相关数据等之前。
让它变得强大，处理没有人可以做到现在因为sumfin’出错了…
如果我没有编辑整个文件的东西，那需要悲观的锁定，我会看看我的设计，因为它不适合用途。