Как хранить список часто меняющегося порядка в Postgres?

Question

[egorkozelskij]

Здравствуйте!

Подскажите общепринятые подходы для хранения элементов в таблице, которые могут довольно часто менять свой порядок.

Например:
id --- name
1 --- item_1
2 --- item_2
3 --- item_3

Задача максимально эффективно хранить элементы, если будут появлятся задачи типа: сделать элемент item_3 вторым по порядку.

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

Находил еще вариант с строковым индексом

id --- name
'a' --- item_1
'b' --- item_2
'c' --- item_3

И после перестановки нужно только вычислить новый индекс 1го элемента:
id --- name
'a' --- item_1
'ab' --- item_3
'b' --- item_2

И как я понимаю в последнем случае логика вычисления индекса ложится на сторону сервера, а не бд?
Подскажите, как решается подобная задача в БД?

Answer 1

[#]

проблема надумая
- с точки зрения БД, предпочтительно {id, name, order}
- менять порядок логично в промежуточной логике (в зависимости от архитектуры, она может быть и на фронте, и на на беке, и на мидл леере).. и при необходимости сохранять изменения

ps egorkozelskij, если вас устроит key-value, есть https://www.aerospike.com/lp/aerospike-community-e... но кажется там, все равно, стартовая конфигурация железа от 8 Гб RAM

Comments

[egorkozelskij]

В случае с {id, name, order} и 1миллионом записей, если мне нужно передвинуть последний элемент на позицию первого, то последует миллион операция обновления индекса. Это же максимально неэффективно.
При том, что операция изменения порядке может происходить довольно часто.

[#]

egorkozelskij, у вас name является уникальной сущностью? есть связи с другими таблицами? если да и да, то уникальный id следует иметь..

.. а все остальное - вероятно объективные сложности вашего проекта

тут все просто:
- если сложно сохранять - не сохраняйте, но если надо сохрянять.. ждете чуда? его не будет
- если индекс не оябзателен - его не надо обновлять.. точно нужен?.. опять не будет чуда
- нужен супер перфоманс? а еще и надежность? - используйте in-memory-db.. с резервированием и репликацией.. деньги есть?

[#]

egorkozelskij,

В случае с {id, name, order} и 1миллионом записей, если мне нужно передвинуть последний элемент на позицию первого, то последует миллион операция обновления индекса.

с чего вдруг? ))
спорим - одна? )))))))))))))

[egorkozelskij]

#, А объяснение можно?
Почему одна перестановка то?