Эффективный способ хранения переопределяемых элементов в базе данных
Итак, у меня есть таблица избранных пользователей. Там их несколько миллионов.
В настоящее время они имеют только три столбца: id (pk), userId и someFkRef. Там есть индекс на userId, чтобы я мог быстро выбирать избранных пользователей.
В настоящее время они упорядочены с помощью id, который фактически является только порядком вставки. Мы хотели бы предложить пользователю возможность переупорядочить свои фавориты, скорее всего, посредством какого-то взаимодействия с перетаскиванием.
Мой первый (и я подозреваю наивный) подход к этому будет просто добавить столбец order и составной индекс над userId, order. Однако при отражении, когда пользователь перемещает свой элемент на некоторое расстояние по списку, все промежуточные строки между начальным положением позиции и конечной позицией будут нуждаться в их пересчитанном столбце order, и, следовательно, индекс тоже.
Это (скорее всего) плохой.
Прежде чем я потрачу возраст, пытаясь точно определить, насколько плохо, мне интересно, есть ли лучшее представление на основе таблиц, которое дешевле манипулировать с видами операций, описанными выше.
Ответы
Ответ 1
Для взаимодействия с перетаскиванием лучшая ставка является приоритетом. Вы начинаете с приоритетов 1, 2, 3 и т.д., Как порядок сортировки.
Но тогда пользователь хочет переместить элемент 5 между 1 и 2. Voila! Дайте ему значение 1.5. Никакие другие значения не должны меняться. Обновление индекса позаботится об остальном.
Для этого приоритет необходимо сохранить как число с плавающей запятой. Это может быть проблемой. Кроме того, достаточно большое количество изменений может привести к тому, что будут продвигаться пределы плавающей запятой. Итак, если пользователь пытается взять последний элемент и вставить его между первыми двумя, он/она может уйти с ним около нескольких десятков раз или около того.
Вы можете исправить это с помощью процесса, который периодически переназначает число для одного (или всех пользователей, если в пакетном режиме), начиная с 1.
Ответ 2
Если вам не нужно манипулировать someFkRef между пользователями (например, получить список пользователей, заинтересованных в чем-то), тогда у вас может быть только одна запись для каждого пользователя с упорядоченным списком someFkRef (refA, refB).
Но это форма де-нормализации, и поскольку у нее есть некоторые недостатки, это действительно зависит от ваших потребностей (и ваших будущих потребностей, вот где наступает проблема)
Ответ 3
Не уверен, что ваши зависимые ссылки могут быть в поле ID, но подумали ли вы о том, чтобы переписать его? Я думаю, что есть SET IDENTITY INSERT = ON или некоторые такие, которые вы можете сделать.
Я понимаю, что это странная вещь, которую можно предложить, но, учитывая то, что вы пытаетесь сделать, это может иметь смысл, и вы получите наименьшее количество накладных расходов.
