Заказать товары с одной записью - PullRequest
0 голосов
/ 24 апреля 2018

Обзор высокого уровня с простым целым числом order значение, чтобы понять мою точку зрения:

   id (primary)   |    order (sort)   |    attributes .. 
----------------------------------------------------------
    ft8df34gfx             1                   ...
    ft8df34gfx             2                   ...
    ft8df34gfx             3                   ...
    ft8df34gfx             4                   ...
    ft8df34gfx             5                   ...

Обычно было бы легко изменить order (например, если пользователь перетаскивает элементы списка на входной стороне): перемещать элемент вокруг, вычислять новые значения order и обновлять затронутые элементы в БД с новыми order .


Ограничения:

  • Не имеет всех предметов одновременно, только их подмножество (подумайте, нумерация страниц)
  • Обновлять только один элемент в дБ, если перемещен один элемент (1 элемент в смену)

Моя первоначальная идея:

Используйте эпоху как order и добавьте что-то уникальное, чтобы избежать дублирования времени эпохи, например, <epoch>#<something-unique-to-item>. Начальное значение - время вставки (поэтому порядок по умолчанию сначала самый новый).

Клиент / сервер (который вычисляет order) знает эпоху для каждого элемента в подмножестве элементов, которые он имеет.

Если элемент смещен, посмотрите на эпоху предыдущего и следующего элемента (если есть предыдущий или следующий - может быть перемещен на первый или последний), выберите значение между и обновите. Более 1 смены? Повторите процесс.

Но ..

  1. Если элементы сдвинуты достаточно много раз, значения эпох становятся ближе и ближе друг к другу, пока вы не можете найти середину с целыми числами.
    • Добавить много нулей в эпоху при вставке? Все еще достигать предела в какой-то момент.
  2. Если элемент смещен на первый или последний элемент и на предыдущей или следующей странице есть элементы (помните, нумерация страниц), мы не знаем этих значений и не можем надежно найти «значение между».
    • Выбрать 1 дополнительный скрытый элемент с предыдущей и следующей страницы? Запросы усложняются ..

Это вообще возможно? Какой тип / значение я должен использовать как order?

1 Ответ

0 голосов
/ 25 апреля 2018

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

Предполагая, что ключи раздела / сортировки, о которых вы говорите, предназначены для вторичного индекса, я рекомендую хранить для порядка натуральные числа (1, 2, 3,и т. д.), а затем обновляйте их по мере необходимости.

По сути, вам нужно рассмотреть три случая:

  • Добавление нового элемента - Вы выполнитезапрос на ключ вторичного раздела с ScanIndexForward = false (для изменения порядка результатов) с проекцией на атрибут «порядок», ограниченный 1 результатом.Это покажет вам максимальную стоимость заказа.Заказ нового предмета будет просто таким максимальным значением + 1.
  • Удаление предмета - Поначалу это может показаться тревожным, но вы можете свободно удалять предметы, не касаясь приказов других предметов,Возможно, у вас есть некоторые пробелы в последовательности заказа, но это нормально.
  • Изменение порядка - На самом деле нет способа обойти это;Ваша логика приложения должна будет взять список затронутых предметов и записать все их новые заказы в таблицу.Если раньше использовались элементы (A, 1), (B, 2), (C, 3) и они были заменены на A, C, B, вам нужно будет написать в B и C, чтобы соответствующим образом обновить их заказы.поэтому они заканчиваются как (A, 1), (C, 2), (B, 3).
...