Каков наилучший подход к проектированию базы данных для больших данных на пользователя? - PullRequest
0 голосов
/ 23 апреля 2020

Я получил задание создать веб-приложение для "опроса" в ресторане, которое будет просто отслеживать статус пользователя относительно ресторана (будет объяснено позже), и если этот ресторан ваш любимый. В основном это все данные, которые у меня есть и которые мне нужны. У меня также есть категории и подкатегории, но они не так широко используются.

Таким образом, мы говорим о 386 ресторанах в целом (с возможностью добавить больше). После регистрации каждый пользователь может заполнить данные, а затем сохранить их для последующего использования в приложении. Пользователь может установить один из трех вариантов состояния (0 - никогда не было, 1 - планирует go в ближайшее время, 2 - отправился туда), и он также может добавить в избранное.

Мое текущее решение - это :

  • Я веду только записи тех, кто имеет статус 1 и 2, 0 игнорируется и не сохраняется в БД
  • Также, если кто-то меняет статус с 2 или 1 на 0, запись получает удален
  • Я храню полные данные JSON ресторанов в локальном хранилище, затем, когда пользователь входит в систему, сервер получает все свои данные (скажем, 20 записей), а затем данные объединяются по идентификатору со списком stati c local storage
  • Итак, в конце этот список stati c JSON преобразуется таким образом, что записи, найденные в базе данных, добавляются к объекту в новом свойство, которое называется записью. Для тех, у кого нет записи, добавлено свойство пустой записи.

enter image description here

enter image description here

Итак, наконец, мой вопрос: правильный ли это / оптимальный способ сделать это? Сначала у меня была идея инициализировать все 368 ресторанов для каждого зарегистрированного пользователя, а затем получить к ним доступ по индексу, потому что таким образом я бы знал, что идентификатор 0-367 - это пользователь 1, идентификатор 367 - 735 - это пользователь два и * 1044. *. Но, как вы можете видеть только для 10 пользователей, есть записи 3k +, которые, вероятно, останутся пустыми / нулевыми.

С другой стороны, моя цель в этой текущей реализации состояла в том, чтобы разделить работу по интерфейсу и бэкэнду, потому что данные ресторана это stati c, но меня беспокоит, когда / если количество записей достигнет, скажем, миллиона / 10 миллионов. В этом случае все записи будут разбросаны, и кто-то может иметь запись с идентификатором 4, а затем с идентификатором 904,302.

Вот текущая таблица, которую я использую:

enter image description here

Следует отметить, что я сделал индекс на каждой странице и постарался максимально оптимизировать его.

1 Ответ

1 голос
/ 23 апреля 2020

Это не похоже на большое количество данных.

Просто сохраняйте каждую запись статуса для каждого пользователя и каждого ресторана. Время изменения статуса, вероятно, гораздо важнее, чем вы думаете. Также может быть другая информация, которую вы хотите. Возможно, кто-то, кто никогда не был в ресторане, что-то слышал об этом, и вы хотите включить это.

Затем суммируйте данные по транзакциям, которые вам нужны.

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

...