我有以下表格：
======================= =======================
| galleries | | images |
|---------------------| |---------------------|
| PK | gallery_id |<--\ | PK | image_id |
| | name | \ | | title |
| | description | \ | | description |
| | max_images | \ | | filename |
======================= \-->| FK | gallery_id |
=======================
我需要实现一种方法，将与图库关联的图像分类为特定顺序。据我所知，关系数据库不是为分层排序而设计的。
我也希望为并发的可能性做好准备，即使它非常不可能成为我当前项目中的一个问题，因为它是一个单用户应用程序。 （因此，此处的优先级是处理允许用户重新排列顺序）。
我不确定最好的解决方法，因为我从未在数据库中实现排序，并且不熟悉并发性。因此，我已经阅读了关于锁定MySQL表的内容，并且我不确定这是否应该实现它。
以下是我的两个想法：
将一个名为order_num的列添加到images表中。锁定表格并允许客户重新排列图像的顺序，然后更新表格并解锁。
将一个名为order_num的列添加到images表中（与上面的创意1一样）。允许客户端一次更新一个图像的位置而不锁定。
谢谢！
答案 0 :(得分：4)
这是我的想法：你不想把太多的工时投入到不太可能发生的问题中。因此，采取一种不会造成很多副作用的简单解决方案，如果出现问题，请稍后再修复。
在基于Web的世界中，您不希望锁定表以供用户进行编辑，然后等待它们完成以解锁表。在这种情况下，用户1可能永远不会回来，他们可能会丢失会话，或者他们的浏览器可能会崩溃等等。这意味着您必须做很多工作来确定何时解锁表格，以及让用户2知道的代码表被锁定了，他们无法用它做任何事情。
我建议使用这个设计：让它们进入编辑模式，可能在浏览器中，使用一些javascript。他们可以按顺序拖动图像直到他们开心，然后他们全部提交订单。您将单个事务中的order_num字段更新到数据库。
在这种情况下，最糟糕的事情是用户1和用户2同时进行编辑，最后编辑的是保留订单的人。也许他们会在同一时间更新，但数据库会处理它，因为它会排队交易。
这个问题的后退是，任何被覆盖的订单都必须再次执行。令人讨厌，但没有任何损失，实现这一点的代码比处理锁定的代码简单 简单。
我讨厌回避你的问题，但那是我对它的看法。
答案 1 :(得分：1)
如果您不希望“按用户排序”，order_num列似乎是正确的方法。
如果您为存储子系统选择InnoDB，则可以使用事务，而不必锁定表。
答案 2 :(得分：0)
关系数据库和层次结构： 我使用id（自动增量）和父列来实现层次结构。父项为零始终是根元素。您可以按id，parent订购。
并发： 这是处理并发的简单方法。使用版本列。如果自用户1开始编辑后版本已更改，则阻止保存，提议重新加载编辑。每次成功编辑后增加版本。