Структурирование моих данных - Firebase

Question

Я создаю приложение списка групп прототипов. Я хочу, чтобы следующие объекты:

• пользователя
• Список
• Item
• Комментарий

Я думаю, что я должен структурировать это следующим образом:

http://myapp.firebase.io/user/ 
http://myapp.firebase.io/user/uid/lists/ 
http://myapp.firebase.io/list/ 
http://myapp.firebase.io/item/listid/ 
http://myapp.firebase.io/comment/itemid 

где http://myapp.firebase.io/user/uid/lists/ указывает на список уникальных идентификаторов, http://myapp.firebase.io/item/listid/ указывает на все объекты предметов для данного списка, а http://myapp.firebase.io/comment/itemid указывает на все комментарии по данному предмету.

Имеет ли смысл эта структура? Причина, по которой я делал это так, вместо того, чтобы больше вложить (то есть http://myapp.firebase.io/list/listid/item/ для элементов и http://myapp.firebase.io/list/listid/item/itemid/comment), состоит в том, что в документации говорится, что всякий раз, когда вы выбираете объект, вы выбираете всех детей. Иногда (возможно, даже большую часть времени) я хочу получать элементы списка, но не комментарии каждого элемента. Я могу только хотеть сделать это, когда пользователь нажимает на элемент.

Answer 1

В базе данных NoSQL вы должны смоделировать свои данные для того, как вы собираетесь их использовать. Я настоятельно рекомендую прочитать это article on NoSQL data modeling.

Структура верхнего уровня кажется прекрасной и не нарушает Firebase's recommendation to limit nesting of data. Но есть много других мест, где вы все равно можете ошибаться (что является одной из причин, почему этот вопрос слишком широк для Stack Overflow, но я попробую ответить на некоторые из них в любом случае).

Я бы отделить списки пользователя в отдельный узел верхнего уровня:

/userlists/$uid/$listid 

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

/usernames/$uid 

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

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

В базе данных NoSQL вы должны моделировать свои данные для доступа к вашему приложению.. Я настоятельно рекомендую прочитать это article on NoSQL data modeling.

После этого выпишите список прецедентов и посмотрите, как вы можете наиболее легко получить доступ к данным для него. Либерально denormalize и иногда дублируйте данные, чтобы они соответствовали прецедентам. Используйте multi-location updates для сохранения денормализованных и дублированных данных в синхронизации с основным объектом.