2017-01-30 1 views
0

Я новичок в Firebase и NoSQL, я создал структуру для своего приложения, и у меня есть некоторые вопросы.Дублирование структуры Firebase

Мой stucture:

ROOT 
| 
+-- USERS 
|  | 
|  +-- USER_ID 
|   | 
|   +-- USERNAME 
|   | 
|   +-- DISPLAY_NAME 
|   | 
|   +-- PROFILE_PICTURE_URL 
|   | 
|   +-- POST_COUNT 
| 
+-- CATEGORIES 
|  | 
|  +-- CATEGORY_ID 
|   | 
|   +-- NAME 
|   | 
|   +-- POST_COUNT 
| 
+-- POSTS 
|  | 
|  +-- POST_ID 
|   | 
|   +-- MESSAGE 
|   | 
|   +-- USER_ID 
|   | 
|   +-- USERNAME 
|   | 
|   +-- DISPLAY_NAME 
|   | 
|   +-- PROFILE_PICTURE_URL 
|   | 
|   +-- CATEGORIES 
|   |  | 
|   |  +-- CATEGORY_ID 
|   | 
|   +-- LIKE_COUNT 
| 
+-- USERS_POSTS 
|  | 
|  +-- USER_ID 
|   | 
|   +-- POST_ID 
|     | 
|     +-- MESSAGE 
|     | 
|     +-- USER_ID 
|     | 
|     +-- USERNAME 
|     | 
|     +-- DISPLAY_NAME 
|     | 
|     +-- PROFILE_PICTURE_URL 
|     | 
|     +-- CATEGORIES 
|     |  | 
|     |  +-- CATEGORY_ID 
|     | 
|     +-- LIKE_COUNT 
| 
+-- CATEGORIES_POSTS 
|  | 
|  +-- CATEGORY_ID 
|   | 
|   +-- POST_ID 
|     | 
|     +-- MESSAGE 
|     | 
|     +-- USER_ID 
|     | 
|     +-- USERNAME 
|     | 
|     +-- DISPLAY_NAME 
|     | 
|     +-- PROFILE_PICTURE_URL 
|     | 
|     +-- CATEGORIES 
|     |  | 
|     |  +-- CATEGORY_ID 
|     | 
|     +-- LIKE_COUNT 
| 

Я спрашиваю себя, если эти вещи хороши или нет?

  • Должности дублируются много раз.
  • Информация о пользователе присутствует в каждом посте, возможно, мне просто нужен идентификатор пользователя и запросить информацию пользователя позже?
  • Должен ли я извлечь «likeCount» в другом объекте?
  • Когда я хочу обновить пользователя или сообщение (или «likeCount»), у меня есть много обновлений.

Заранее благодарю вас!

ответ

1

Возникает вопрос немного расплывчато, но вот некоторые мысли

Столбы дублируется много раз.

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

Информация о пользователе присутствует в каждом посте, возможно, мне просто нужен идентификатор пользователя и запросить информацию о пользователе позже?

Исправить! В этом случае дублирующиеся данные, вероятно, не нужны. Просто uid в сообщении позволит вам собрать остальные данные пользователя, когда это необходимо

Должен ли я извлечь «likeCount» в другом объекте?

Это зависит. Наличие одного счета позволяет легко получить количество понравившихся, но не ссылается на тех, кому это нравится, поэтому вы потеряете это соединение. С другой стороны, вы можете просто сохранить узел с uid, которому понравился пост. Это было бы очень быстро, чтобы подсчитать и поддержать, кому это понравилось.

Когда я хочу обновить пользователя или сообщение (или «likeCount»), у меня есть много обновлений .

Не совсем. Если подобный счет хранится только в одном месте (с сообщением), это просто увеличивает один узел. Обновление счетчика сообщений в пользовательском узле, а не большой сделки.

В общем, когда вы хотите «подсчитать» вещи в Firebase, вы можете: a) читать во всех узлах и подсчитывать их в коде, или b) где-то поддерживать счетчик и увеличивать его на лету. Учетный узел обычно является способом сделать так, чтобы вы направились в правильном направлении.

+0

Спасибо за ваш ответ! Что касается дублированных данных пользователя в каждом сообщении, вы сказали: «В этом случае дублирующиеся данные, вероятно, не нужны», но если я хочу отобразить пользователя с сообщением (например, например, facebook или twitter), я должен запросить данные пользователя после отправить данные или дублировать? – Pipiks

+0

@Pipiks Я бы предложил загрузить почтовые данные для каждого сообщения, которое будет содержать идентификатор пользователя, а затем данные пользователя загрузки. Так как у вас есть uid, вы можете напрямую обращаться к пользователю через watchSingleEvent (Swift) в/users/uid, что позволяет избежать выполнения запроса, который более ресурсоемкий, чем наблюдение. – Jay

+0

Спасибо большое :) – Pipiks

Смежные вопросы