Я получил задание создать веб-приложение для "опроса" в ресторане, которое будет просто отслеживать статус пользователя относительно ресторана (будет объяснено позже), и если этот ресторан ваш любимый. В основном это все данные, которые у меня есть и которые мне нужны. У меня также есть категории и подкатегории, но они не так широко используются.
Таким образом, мы говорим о 386 ресторанах в целом (с возможностью добавить больше). После регистрации каждый пользователь может заполнить данные, а затем сохранить их для последующего использования в приложении. Пользователь может установить один из трех вариантов состояния (0 - никогда не было, 1 - планирует go в ближайшее время, 2 - отправился туда), и он также может добавить в избранное.
Мое текущее решение - это :
- Я веду только записи тех, кто имеет статус 1 и 2, 0 игнорируется и не сохраняется в БД
- Также, если кто-то меняет статус с 2 или 1 на 0, запись получает удален
- Я храню полные данные JSON ресторанов в локальном хранилище, затем, когда пользователь входит в систему, сервер получает все свои данные (скажем, 20 записей), а затем данные объединяются по идентификатору со списком stati c local storage
- Итак, в конце этот список stati c JSON преобразуется таким образом, что записи, найденные в базе данных, добавляются к объекту в новом свойство, которое называется записью. Для тех, у кого нет записи, добавлено свойство пустой записи.
![enter image description here](https://i.stack.imgur.com/RND8u.jpg)
![enter image description here](https://i.stack.imgur.com/3hJYx.jpg)
Итак, наконец, мой вопрос: правильный ли это / оптимальный способ сделать это? Сначала у меня была идея инициализировать все 368 ресторанов для каждого зарегистрированного пользователя, а затем получить к ним доступ по индексу, потому что таким образом я бы знал, что идентификатор 0-367 - это пользователь 1, идентификатор 367 - 735 - это пользователь два и * 1044. *. Но, как вы можете видеть только для 10 пользователей, есть записи 3k +, которые, вероятно, останутся пустыми / нулевыми.
С другой стороны, моя цель в этой текущей реализации состояла в том, чтобы разделить работу по интерфейсу и бэкэнду, потому что данные ресторана это stati c, но меня беспокоит, когда / если количество записей достигнет, скажем, миллиона / 10 миллионов. В этом случае все записи будут разбросаны, и кто-то может иметь запись с идентификатором 4, а затем с идентификатором 904,302.
Вот текущая таблица, которую я использую:
![enter image description here](https://i.stack.imgur.com/QyhZd.jpg)
Следует отметить, что я сделал индекс на каждой странице и постарался максимально оптимизировать его.