Как моделировать классические пользовательские-> многие данные приложения отношений в NoSQL

Question

Я заметил, что решения NoSQL, предоставляемые такими гигантами, как Google NoSQL, Firestore и DynamoDB, не имеют запросов на соединение (я не включаю в это MongoDB и RethinkDB).

Мне нравится идея использовать их для простоты и экономичности.

Мне нравятся базы данных документов в стиле JSON, и я не хочу возвращаться к темным дням VARCHAR и т. Д. Поэтому мне интересно, насколько жизнеспособным является создание 99% баз данных для Интернета.

Возьмите этот сценарий:

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

Относительно это было бы просто:

user: { ..., projects: [projectId1, ...] }
project: { ..., users: [userId1, ...] }

Затем вы можете объединиться, чтобы показать некоторые основные сведения о списке проектов и т. Д.

Но как быть с нереляционной NoSQL? Как бы мы денормализовали это?

Вы бы просто имели:

user: { no project IDs },
project: { users: [userId1, ...] }

И затем для страницы списка проектов или страницы сведений о проекте вы просто запускаете фильтр для каждого проекта и возвращаете те, членом которых является пользователь? Это то, что NoSQL процветает с точки зрения эффективности? Я не имею дело с огромными наборами данных здесь, я ожидаю, что проекты будут <10k и не будут большими документами. Спасибо. </p>

Answer 1

Возможная схема базы данных для вашего варианта использования приложения может быть:

Firestore-root
   |
   --- users (collection)
   |    |
   |    --- userId (document)
   |         |
   |         --- userName: "John"
   |         |
   |         --- emailAddress: "john@gmail.com"
   |         |
   |         --- uid: "uidOfTheUser"
   |         |
   |         --- //other user data
   |
   --- projects (collection)
         |
         --- projectId (document)
               |
               --- projectName: "ProjectName"
               |
               --- projectId: "projectId"
               |
               --- users: ["uidOfTheUser", "uidOfTheUser"]

Используя эту схему базы данных, вы можете просто:

• Получить все проекты всех пользователей, используя всего лишь CollectionReference:

  FirebaseFirestore rootRef = FirebaseFirestore.getInstance();
  CollectionReference projectsRef = rootRef.collection("projects");
  projectsRef.get().addOnCompleteListener(/* ... */);
  

• Получить все проекты, которые соответствуют одному пользователю:

  FirebaseFirestore rootRef = FirebaseFirestore.getInstance();
  Query query = rootRef.collection("projects").whereArrayContains("users", uid);
  query.get().addOnCompleteListener(/* ... */);
  

Как бы мы денормализовали это?

В этом случае нет необходимости денормализовать данные. Тем не менее, эта практика denormalization является обычной практикой, когда дело доходит до Firebase. Если вы новичок в базах данных NoQSL, я рекомендую вам посмотреть это видео, Денормализация нормальна с базой данных Firebase для лучшего понимания. Это для базы данных реального времени Firebase, но к Cloud Firestore применяются те же правила.

Кроме того, когда вы дублируете данные, нужно помнить одну вещь. Точно так же, как вы добавляете данные, вы должны поддерживать их. Другими словами, если вы хотите обновить / обнаружить элемент, вы должны делать это в каждом месте, где он существует.

Пожалуйста, смотрите также:

• Как правильно структурировать данные такого рода в хранилище?

Как упомянул @FrankvanPuffelen в своем комментарии, пожалуйста, смотрите также следующие ответы:

• Отношение многие ко многим в Firebase
• Структура данных Firebase и URL