В этом и суть алгоритма: мы отказались от «восстанавливающей» части в пользу динамичности, так сказать
Да, метки могут достигать большой длинны, однако если пользователь перенесёт задачу с меткой «aaaaaaaaaaa» куда-нибудь, пускай, в центр, то, скорее всего, метка станет заметно меньше
В нашем случае в таблице задач есть колонка – lexorank. Соответственно, с помощью ORDER BY в SELECT запросе можно отсортировать по этой колонке.
Пример:
SELECT * from Tasks ORDER BY lexorank
При таком запросе данные будут отсортированы в порядке возрастания ранга: от первого ранга до последнего(прим. от «aaa» до «zzz»)
Нет, связный список мы не рассматривали, потому что «позиции» были более привычны.
Однако идея интересная: каждый элемент списка мог бы указывать на последующий(на id). При добавлении или удалении нам бы нужно было лишь добавить/переставить указатели на элементы. При перемещении элемента нам бы нужно было лишь обновить указатели на элементы. Однако при перемещении пришлось бы обновить три элемента.
Вот пример:
a -> b -> c -> d ->…
Мы хотим переместить элемент c между a и b. Для этого нам бы потребовалось выполнить следующие шаги:
a x b x c x d ->… – удаляем связи элементов(х – нет связи)
a -> c -> b -> d ->… – перестраиваем связи.
Можно заметить, что помимо элемента c изменились ещё и элементы a и b – у них изменился указатель на следующий элемент. Для сохранения порядка элементов это необходимо зафиксировать в бд/на сервере. Также сходу не могу сказать, как бы тогда пришлось подготавливать данные: сначала загрузить данные из бд, а с помощью циклов расставить их в нужном порядке(в соответствии с указателем на следующий), или рекурсивно/последовательно загружать из бд по одной?
Это взято просто для примера. Даже если предположить, что индексы будут расставляться с каким-то шагом, скажем, в 500(500, 1000, 1500...), то при перетягивании второго элемента на место первого, алгоритм был бы таким же, как и описанный ниже: мы бы взяли начальную позицию(для лексорангов – «ааа», для чисел пускай будет 1) и индекс первого элемента(сейчас – 500) и посчитали бы среднее((1 + 500) / 2 = 250).
А что будет добавлено между «aa» и «aan»?
Длинна первой строки меньше, чем длинна второй, поэтому их необходимо выровнять. Это можно увидеть под спойлером «Наша реализация нахождения 'средней' строки» под комментарием «Make positions equal».
После выравнивания получится две строки: «aaa» и «aan», между которыми и будет найдена средняя.
PS. Возможно не правильно понял вопрос. Начало раздела
Да, метки могут достигать большой длинны, однако если пользователь перенесёт задачу с меткой «aaaaaaaaaaa» куда-нибудь, пускай, в центр, то, скорее всего, метка станет заметно меньше
Пример:
SELECT * from Tasks ORDER BY lexorank
При таком запросе данные будут отсортированы в порядке возрастания ранга: от первого ранга до последнего(прим. от «aaa» до «zzz»)
Однако идея интересная: каждый элемент списка мог бы указывать на последующий(на id). При добавлении или удалении нам бы нужно было лишь добавить/переставить указатели на элементы. При перемещении элемента нам бы нужно было лишь обновить указатели на элементы.
Однако при перемещении пришлось бы обновить три элемента.
Вот пример:
a -> b -> c -> d ->…
Мы хотим переместить элемент c между a и b. Для этого нам бы потребовалось выполнить следующие шаги:
a x b x c x d ->… – удаляем связи элементов(х – нет связи)
a -> c -> b -> d ->… – перестраиваем связи.
Можно заметить, что помимо элемента c изменились ещё и элементы a и b – у них изменился указатель на следующий элемент. Для сохранения порядка элементов это необходимо зафиксировать в бд/на сервере.
Также сходу не могу сказать, как бы тогда пришлось подготавливать данные: сначала загрузить данные из бд, а с помощью циклов расставить их в нужном порядке(в соответствии с указателем на следующий), или рекурсивно/последовательно загружать из бд по одной?
Это взято просто для примера. Даже если предположить, что индексы будут расставляться с каким-то шагом, скажем, в 500(500, 1000, 1500...), то при перетягивании второго элемента на место первого, алгоритм был бы таким же, как и описанный ниже: мы бы взяли начальную позицию(для лексорангов – «ааа», для чисел пускай будет 1) и индекс первого элемента(сейчас – 500) и посчитали бы среднее((1 + 500) / 2 = 250).
Длинна первой строки меньше, чем длинна второй, поэтому их необходимо выровнять. Это можно увидеть под спойлером «Наша реализация нахождения 'средней' строки» под комментарием «Make positions equal».
После выравнивания получится две строки: «aaa» и «aan», между которыми и будет найдена средняя.
PS. Возможно не правильно понял вопрос. Начало раздела
может помочь разобраться лучше