Проектирование базы данных с заказными упорядоченными подмножествами статического главного списка - PullRequest
0 голосов
/ 18 июня 2019

Вероятно, это простой вопрос о дизайне, но я не профессионал, и мне нужны отзывы.

Я пишу что-то, что, по моему разумному ожиданию, будет иметь несколько тысяч пользователей, но хотелось бы, чтобы его можно было масштабировать для большей пользовательской базы. У меня есть таблица в моей базе данных, состоящая примерно из 10 000 статических элементов, если хотите, главного хранилища. Пользователь выберет какое-то большое подмножество (~ 8000) этих предметов, но может заказать их так, как хочет. С другой стороны, система будет запрашивать только ~ 100 элементов одновременно. Поэтому, если пользователь включен в элемент 2000 своего личного списка, система должна будет определить, какие элементы соответствуют 2001 - 2100, и извлечь их из основного списка.

Аналогия может заключаться в том, что у вас есть хранилище из 10000 песен, и каждый пользователь создает собственный список воспроизведения из 8000 песен, но одновременно в интерфейсе отображается только 100 песен.

Каждый элемент в основном списке содержит нетривиальный объем данных, и, кажется, расточительно копировать эти данные для каждого пользователя. Я полагаю, что есть три варианта, все с компромиссами:

  1. Будьте расточительны: у каждого пользователя есть полная копия данных основного списка, но на этот раз с индексом, который отслеживает порядок. Это самый простой способ, но он приведет к быстрому увеличению размера базы данных.
  2. Создание объекта базы данных с полем, в котором хранится массив, идентифицирующий метки в их произвольном порядке. Поэтому что-то неаккуратное, как [1, 15, 7, 33], скажет, что нужно взять объекты с идентификаторами 1, 15, 7 и 33 из основного списка и расположить их в таком порядке. Это не так уж плохо, но не кажется надежным.
  3. Создать промежуточную таблицу, в каждой строке которой отслеживаются «Пользователь, Индекс, Database_ID». Таким образом, «$ User, 15, 33» говорит, что основной элемент списка 33 должен быть 15-м в пользовательском порядке $ User. Это кажется хорошим компромиссом, но создаст таблицу с очень большим количеством строк. Я волнуюсь, это замедлит запросы.

Я полагаю, что это, вероятно, между 2 и 3, но я просто не очень хорошо чувствую масштаб. Любая идея будет принята с благодарностью.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...