изменения порядка в списке
От: MadHuman Россия  
Дата: 15.11.22 16:43
Оценка:
Как лучше решить задачу?
Есть список записей, которые должны отображаться в UI в определённом порядке и юзер может (должен моч) изменить порядок нужной записи (перетащить выше/ниже относительно других).
Хотелось бы чтоб при таком изменении порядка, изменялась только одна та запись порядок которой относительно других изменился.

С ходу приходит решение в поле order присваивать числовые значения с гигантским шагом между соседними записями и при изменении порядка присваивать в запись значение среднее между теми между которых она помещается.
но при большом количестве изменений можно быстро упереться что дойдём что разница между соседними будет единица и уже значение между не сделать.
Может есть какой вариант лучше?
Отредактировано 15.11.2022 16:44 MadHuman . Предыдущая версия .
Re: изменения порядка в списке
От: s_aa Россия  
Дата: 15.11.22 16:50
Оценка:
MH>С ходу приходит решение в поле order присваивать числовые значения с гигантским шагом между соседними записями и при изменении порядка присваивать в запись значение среднее между теми между которых она помещается.
MH>но при большом количестве изменений можно быстро упереться что дойдём что разница между соседними будет единица и уже значение между не сделать.

Когда\если упрётся, делать общую перенумерацию?
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Re: изменения порядка в списке
От: Stanislav V. Zudin Россия  
Дата: 15.11.22 16:52
Оценка:
Здравствуйте, MadHuman, Вы писали:


MH>Есть список записей, которые должны отображаться в UI в определённом порядке и юзер может (должен моч) изменить порядок нужной записи (перетащить выше/ниже относительно других).

MH>Хотелось бы чтоб при таком изменении порядка, изменялась только одна та запись порядок которой относительно других изменился.

MH>С ходу приходит решение в поле order присваивать числовые значения с гигантским шагом между соседними записями и при изменении порядка присваивать в запись значение среднее между теми между которых она помещается.

MH>но при большом количестве изменений можно быстро упереться что дойдём что разница между соседними будет единица и уже значение между не сделать.
MH>Может есть какой вариант лучше?

А количество записей большое? Меняется часто?
Как вариант: хранить отдельное поле, в котором хранится список ид-торов в нужном порядке. В случае вмешательства пользователя редактироваться будет только это поле, а не сами записи.
_____________________
С уважением,
Stanislav V. Zudin
Re: изменения порядка в списке
От: vsb Казахстан  
Дата: 15.11.22 16:55
Оценка:
Использовать рациональные числа вместо целых

В постгресе 16000 цифр после запятой можно. Для разумных применений вроде должно хватить. Для неразумных — сделай "дефрагментацию".

Можешь имитировать строками. Типа "a", "am", "b" (тут "am" вставлено между "a" и "b") но по-моему это гемор ненужный, если у тебя база умеет в рациональные числа большой длины.
Re[2]: изменения порядка в списке
От: MadHuman Россия  
Дата: 15.11.22 16:55
Оценка:
_>Когда\если упрётся, делать общую перенумерацию?
можно, но лучше бы что-то хитрее, чтоб гарантированно оставаться в рамках изменения только одной записи..
Re: изменения порядка в списке
От: paucity  
Дата: 15.11.22 19:17
Оценка:
Здравствуйте, MadHuman, Вы писали:


Добавить в запись два поля prev_id, next_id; где _id — что-то уникально идентифицирующее каждую запись.

ЗЫ. можно и одно поле, но два удобнее, имхо
Отредактировано 15.11.2022 19:19 paucity . Предыдущая версия .
Re: изменения порядка в списке
От: · Великобритания  
Дата: 15.11.22 19:41
Оценка: 2 (1)
Здравствуйте, MadHuman, Вы писали:

MH> Может есть какой вариант лучше?

Структура linked list. У каждой записи будет ссылка на следующую. При перемещении придётся менять максимум две записи — предыдущая и текущая.
avalon/3.0.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: изменения порядка в списке
От: · Великобритания  
Дата: 16.11.22 19:02
Оценка:
Здравствуйте, paucity, Вы писали:

P>Добавить в запись два поля prev_id, next_id; где _id — что-то уникально идентифицирующее каждую запись.

P>ЗЫ. можно и одно поле, но два удобнее, имхо
Не, можно и одно, т.к. можно искать записи по критерию where prev_id=?.
Другое дело, я тут подумал, что такой способ не позволяет сделать простой order by, приходится рекурсивный CTE ваять, что может плохо отразиться на производительности как минимум... Ну или сортировать на клиенте.
В общем, такое ощущение, что шило на мыло меняется.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 16.11.2022 19:03 · . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.