Реализация порядка в PHP / MySQL CMS и работа с параллелизмом

Question

У меня есть следующие таблицы:

=======================           =======================
| galleries           |           | images              |
|---------------------|           |---------------------|
| PK | gallery_id     |<--\       | PK | image_id       |
|    | name           |    \      |    | title          |
|    | description    |     \     |    | description    |
|    | max_images     |      \    |    | filename       |
=======================       \-->| FK | gallery_id     |
                                  =======================

Мне нужно реализовать способ сортировки изображений, связанных с галереей, в определенном порядке.Насколько я понимаю, реляционные базы данных не предназначены для иерархического упорядочения.

Я также хочу подготовиться к возможности параллелизма, даже если крайне маловероятно, что станет проблемой в моем текущем проекте, так как это однопользовательское приложение.(Таким образом, приоритет здесь состоит в том, чтобы позволить пользователю изменить порядок).

Я не уверен, что лучший способ сделать это, так как я никогда не реализовывал порядок в базе данных и не знаком с параллелизмом,Из-за этого я прочитал о блокировке таблиц MySQL и не уверен, что это ситуация, в которой я должен это реализовать.

Вот две мои идеи:

1. Добавьте столбец с именем order_num в таблицу images.Заблокируйте таблицу и позвольте клиенту изменить порядок изображений, затем обновите таблицу и разблокируйте ее.

2. Добавьте столбец с именем order_num в таблицу images (простокак идея 1 выше).Разрешить клиенту обновлять одно изображение за раз без блокировки.

Спасибо!

Answer 1

Вот моя мысль: вы не хотите вкладывать слишком много человеко-часов в проблему, которая вряд ли случится.Поэтому возьмите простое решение, которое не вызовет большого количества побочных эффектов, и исправьте его позже, если возникнет проблема.

В мире, основанном на веб-технологиях, вы не хотите блокировать таблицу дляпользователь должен внести изменения, а затем подождать, пока они не закончат, чтобы разблокировать таблицу.Пользователь 1 в этом сценарии может никогда не вернуться, он может потерять свой сеанс, или его браузер может зависнуть, и т. Д. Это означает, что вам нужно проделать большую работу, чтобы выяснить, когда разблокировать таблицу, плюс код, чтобы сообщить пользователю 2что таблица заблокирована, и они ничего не могут с ней сделать.

Я бы предложил этот дизайн вместо этого: позвольте им обоим перейти в режим редактирования, возможно, в браузере, с некоторым javascript.Они могут перетаскивать изображения по порядку, пока не будут довольны, затем они отправляют заказ в полном объеме.Вы обновляете свое поле order_num в одной транзакции для базы данных.

В этом сценарии худшее, что происходит, это то, что пользователь 1 и пользователь 2 редактируют одновременно, и тот, кто редактирует последним, является тем, чей порядок сохраняется.Может быть, они обновляются в одно и то же время, но база данных справится с этим, так как собирается поставить транзакции в очередь.

Откат к этой проблеме заключается в том, что тот, кто получил перезаписанный заказ, должен сделать это снова.Раздражает, но нет потерь, и код для реализации этого на 1010 * намного проще, чем код для блокировки.

Я ненавижу обходить ваш вопрос, но это мои мысли по этому поводу.

Answer 2

Если вы не хотите "сортировать по пользователю", столбец order_num кажется правильным решением. Если вы выбираете InnoDB для своей подсистемы хранения, вы можете использовать транзакции, и вам не нужно будет блокировать таблицу.

Answer 3

Реляционная база данных и иерархия: Я использую id (автоинкремент) и родительские столбцы для достижения иерархии. Родитель ноля всегда является корневым элементом. Вы можете заказать по id, родитель.

Параллелизм: Это простой способ справиться с параллелизмом. Используйте версию столбца. Если версия изменилась после того, как пользователь 1 начал редактирование, заблокируйте сохранение, предложите перезагрузить редактирование. Увеличивайте версию после каждого успешного редактирования.