Как лучше решить задачу?
Есть список записей, которые должны отображаться в UI в определённом порядке и юзер может (должен моч) изменить порядок нужной записи (перетащить выше/ниже относительно других).
Хотелось бы чтоб при таком изменении порядка, изменялась только одна та запись порядок которой относительно других изменился.
С ходу приходит решение в поле order присваивать числовые значения с гигантским шагом между соседними записями и при изменении порядка присваивать в запись значение среднее между теми между которых она помещается.
но при большом количестве изменений можно быстро упереться что дойдём что разница между соседними будет единица и уже значение между не сделать.
Может есть какой вариант лучше?
MH>С ходу приходит решение в поле order присваивать числовые значения с гигантским шагом между соседними записями и при изменении порядка присваивать в запись значение среднее между теми между которых она помещается. MH>но при большом количестве изменений можно быстро упереться что дойдём что разница между соседними будет единица и уже значение между не сделать.
Когда\если упрётся, делать общую перенумерацию?
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
MH>Есть список записей, которые должны отображаться в UI в определённом порядке и юзер может (должен моч) изменить порядок нужной записи (перетащить выше/ниже относительно других). MH>Хотелось бы чтоб при таком изменении порядка, изменялась только одна та запись порядок которой относительно других изменился.
MH>С ходу приходит решение в поле order присваивать числовые значения с гигантским шагом между соседними записями и при изменении порядка присваивать в запись значение среднее между теми между которых она помещается. MH>но при большом количестве изменений можно быстро упереться что дойдём что разница между соседними будет единица и уже значение между не сделать. MH>Может есть какой вариант лучше?
А количество записей большое? Меняется часто?
Как вариант: хранить отдельное поле, в котором хранится список ид-торов в нужном порядке. В случае вмешательства пользователя редактироваться будет только это поле, а не сами записи.
_____________________
С уважением,
Stanislav V. Zudin
В постгресе 16000 цифр после запятой можно. Для разумных применений вроде должно хватить. Для неразумных — сделай "дефрагментацию".
Можешь имитировать строками. Типа "a", "am", "b" (тут "am" вставлено между "a" и "b") но по-моему это гемор ненужный, если у тебя база умеет в рациональные числа большой длины.
_>Когда\если упрётся, делать общую перенумерацию?
можно, но лучше бы что-то хитрее, чтоб гарантированно оставаться в рамках изменения только одной записи..
Здравствуйте, MadHuman, Вы писали:
MH> Может есть какой вариант лучше?
Структура linked list. У каждой записи будет ссылка на следующую. При перемещении придётся менять максимум две записи — предыдущая и текущая.
Здравствуйте, paucity, Вы писали:
P>Добавить в запись два поля prev_id, next_id; где _id — что-то уникально идентифицирующее каждую запись. P>ЗЫ. можно и одно поле, но два удобнее, имхо
Не, можно и одно, т.к. можно искать записи по критерию where prev_id=?.
Другое дело, я тут подумал, что такой способ не позволяет сделать простой order by, приходится рекурсивный CTE ваять, что может плохо отразиться на производительности как минимум... Ну или сортировать на клиенте.
В общем, такое ощущение, что шило на мыло меняется.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай