Допустим, у меня есть большой список элементов, куда пользователь может пойти и добавить элементы в избранное по своему желанию. Затем эти избранные переходят к новому узлу userLikedItems/userUID/.
При сохранении избранного я пытаюсь найти лучший способ сделать это:
Вот мой текущий дублирующий подход:
//duplicating all the data when a user favourites an item into their own node under userLikedItems
{
"hwUjzftGyCgMrRgNv4Djg5F4ZCQ2" : {
"24K Carrot" : {
"effects" : {
"Euphoria" : true,
"Happy" : true,
"Relaxing" : true,
"Sleepy" : true
},
"medical" : {
"Arthritis" : true,
"Bipolar Disorder" : true,
"Chronic Pain" : true,
"Depression" : true,
"Fatigue" : true,
"Inflammation" : true,
"Insomnia" : true,
"Loss of Appetite" : true,
"Migraines" : true,
"PTSD" : true,
"Stress" : true
},
"levels" : "18% - 24%",
"title" : "24K Carrot",
"titleLowercase" : "24k Carrot",
"uid" : "24K Carrot"
},
"2 Pac" : {
"effects" : {
"Cerebral" : true,
"Focus" : true,
"Happy" : true,
"Horny" : true,
"Relaxing" : true,
"Uplifting" : true
},
"medical" : {
"Arthritis" : true,
"Cramps" : true,
"Depression" : true,
"Gastrointestinal Disorder" : true,
"Loss of Appetite" : true,
"Migraines" : true
},
"levels" : "29%",
"title" : "2 Pac",
"titleLowercase" : "2 pac",
"uid" : "2 Pac"
},
}
}
Вот следующий подход, в котором я пытаюсь определить, является ли он лучшей практикой, чем мой текущий подход:
//data stored with only uid:true under user's favourites node
{
"hwUjzftGyCgMrRgNv4Djg5F4ZCQ2" : {
"24K Carrot" : true,
"2 Pac" : true,
"Triple Take" : true,
}
// fetching the rest of the data inside list item
componentDidMount() {
firebase.database().ref('/userLikedItems').child(this.props.user.item.uid).once('value', snapshot => {
const itemData = snapshot.val();
this.setState({
name: itemData.name,
image: itemData.image,
type: itemData.type
});
});
}
Таким образом, когда элемент списка монтируется, я вызываю этот запрос, чтобы получить остальные данные. Я беспокоюсь, что это плохая практика.
Прямо сейчас я дублирую все данные элемента в узле userLikedItems, что означает, что мне не придется выполнять этот запрос для каждого элемента, вместо этого я просто загружу все данные из узла пользователей - проблема в том, что я должен использовать облачная функция для обеспечения согласованности данных при изменении основного элемента, и в моей базе данных много дублирующихся данных, когда вместо этого может быть просто простое логическое значение для каждого элемента.
Я ценю все отзывы!
Ваше здоровье.
Также имейте в виду: вы спрашиваете нас о модели данных, которую мы не видим. Я настоятельно рекомендую добавить JSON, о котором вы говорите, к своему вопросу (в виде текста, без скриншотов). Вы можете получить это, щелкнув ссылку «Экспорт JSON» в дополнительном меню (⠇) на вашем Консоль базы данных Firebase.
@FrankvanPuffelen Спасибо, Пуф, я обновил свой вопрос.
ОК. Это помогает понять вашу модель данных. Но каков ваш вопрос сейчас, имея в виду, что «лучший» или «хороший» часто субъективны (особенно в базах данных NoSQL, где модель данных часто зависит от ваших вариантов использования). Если вы новичок в моделировании данных NoSQL, я рекомендую прочитать Моделирование данных NoSQL.
@FrankvanPuffelen Я снова обновил свой вопрос, в основном я ищу отзывы о двух подходах к сохранению избранного пользователя. В одном методе я сохраняю весь узел элемента, второй подход будет сохранять только uid с логическим значением true, а затем загружать данные для этого узла, когда это нужно пользователю (на странице сведений при нажатии элемента списка)
Оба являются допустимыми подходами. Когда речь идет о моделировании данных NoSQL, не существует единого «это правильный путь», так как это зависит от вариантов использования вашего приложения, от того, какой стиль вы предпочитаете, заботитесь ли вы о размере хранилища, а не о потреблении полосы пропускания и т. д.



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


Вопросы, которые вы задаете, сейчас довольно самоуверенны. Такие вещи, как «лучший» и «плохой подход», не являются объективными, поэтому приведут к мнениям, а не к фактам. Если у вас есть модель данных, которая работает, но не работает так, как вы ожидаете в определенном варианте использования, лучше спросить об этом.