Проблема взаимоотношений с базой данных Firebase - хранение выбранных элементов для пользователей - PullRequest
0 голосов
/ 26 июня 2018

Таким образом, я определенно пожарная база и просто вообще нубл нуб на данный момент. вот моя проблема.

У меня есть такой набор данных

-items
 --id1
   theData
 --id2
   theData
 --id3
   theData
 --id4
   theData      

У меня есть пользователи, которые выберут подмножество этих данных. Пример пользователя A и пользователя B прямо сейчас.

-itemSelected
 ---UserA
    ---Id1  (different than item key)
       theData from items id1 (with items id1 key included so I can reference)
    ---Id2  (different than item key)
       theData from items id3 (with items id3 key included so I can  reference)
  ---UserB
    ---Id1 (different than item key)
       theData from items id1 (with items id1 key included so I can reference)
    ---Id2 (different than item key)
       theData from items id4 (with items id4 key included so I can reference)

Имея более структурированный фон SQL, я чувствую, что поступаю неправильно. Когда я разрабатываю, я вижу, где, если я изменю данные элементов, у меня будут плохие данные в моих документах пользовательских данных. Я до сих пор в моем проекте, и это не такой большой проект. Я хотел бы закончить его с помощью базы данных Firebase в реальном времени, и мне бы хотелось поработать над этим noSql. так, что я пропускаю или делаю неправильно, как это должно быть настроено. Или я должен просто перейти на Firestore и если да, то как это решит мою проблему.

К вашему сведению - причина, по которой я нуждаюсь в ссылке, заключается в том, что бывают случаи, когда эти 2 фрагмента данных необходимо сравнивать, чтобы я мог правильно отображать таблицы. Я думаю, что ключи - это естественный способ сравнения данных. Снова я мог бы быть очень склонным к SQL там.

Надеемся, что есть некоторые специалисты по noSql или firebase, которые могут предложить некоторые решения. Спасибо!

Обновление

На основании ответа респондента Брайана Массота, я думаю, что это новая структура.

-items
 --id1
   theData
 --id2
   theData
 --id3
   theData
 --id4
   theData      

У меня есть пользователи, которые выберут подмножество этих данных, но вместо хранения копий данных просто сохранят значение ключа идентификаторов элементов и логическое значение true для выбранных. Пример пользователя A и пользователя B прямо сейчас.

-itemSelected
 ---UserA
    ---Id1  (different than item key)
       id1KeyFromItems: "True"
    ---Id2  (different than item key)
       id3KeyFromItems: "True"
  ---UserB
    ---Id1 (different than item key)
       id1KeyFromItems: "True"
    ---Id2 (different than item key)
       id4KeyFromItems: "True"

Итак, одна из последних проблем, которую я вижу, это то, что я в настоящее время отображаю данные, выбранные пользователем, в другой таблице, поэтому я изначально записал все выбранные данные в профиль userA или UserB в базе данных firebase. Так что я мог бы просто подписаться на него и показать его оттуда. Если я перейду к логическому маршруту, как я могу отобразить только данные из элементов, выбранных пользователем А, если я храню только ключи?

Ответы [ 2 ]

0 голосов
/ 30 июня 2018

Итак, я прошел через это. Брайан помог мне в этом, поэтому я проголосовал за его ответ, но я выкладываю полный ответ здесь, чтобы другие могли получить пользу. Я пытался сохранить первоначальный вопрос как можно более сложным, но я понимаю, что это сложно, и, возможно, это не лучший форум, но я не мог найти ответ где-либо еще, и у меня был конкретный вариант использования, которым я теперь могу поделиться с код.

Вариант использования для суммирования. У меня есть предметы, хранящиеся в базе огня. Пользователь собирается выбирать из пунктов. Мне нужно хранить то, что они выбирают, но сохранять данные как можно более удобными. Брайан предложил хранить только тот ключ, который в порядке. Но я отображал то, что пользователь выбрал в элементе div в пользовательском интерфейсе, поэтому, по существу, если бы я не сохранял данные в своем профиле, мне нужно было бы фильтровать данные оригинальных элементов (я понял это после публикации Брайана), основываясь на сохраненных ключах. в моем профиле пользователя.

Я - приложение React, поэтому я подключил Реселект и использовал селекторы, чтобы загрузить 2 части данных, в которых у меня были совпадения, с фильтрами и связал их через избыточность в компонентах.

Если вы новичок в селекторах, это видео было очень полезно для меня, и это решение было подключено.

https://www.youtube.com/watch?v=XCQ0ZSr-a2o

Соответствующий код для селектора здесь. В основном вы берете список элементов и список userSelectedItems (который является просто ключами / идентификаторами) и сравниваете их. Если они совпадают, то фильтр будет иметь значение true для нового отфильтрованного списка.

Вот мой селектор.

export function getUser(state) {
   return state.User;
 }

export function getUserItemsList(state) {
  return getTeam(state).list;
 }


export function getItemsList(state) {
 return state.Items.list
}

export function getUserItemsFilter(userItems, items) {

  const selectedItems = items.filter(
    item => userItems.some(userItem => userItem.itemKey === item.key));
   return selectedItems
 }

 export const ItemSelector = createSelector(
  getUserItemsList,  //pick off piece of state
  getItemsList,  //pick off piece of state
  getUserItemsFilter //last argument that runs for Item Selector, do processing here
 );

Вернитесь в созданный вами компонент селектора и подключите его к mapStateToProps следующим образом.

 const mapStateToProps = state => {
  return {
   itemsSelected: ItemSelector(state),
   }
}


const mapDispatchToProps = Object.assign(
  {},
  userActions,
);

export default withRouter(connect(mapStateToProps, mapDispatchToProps)(UserPage));

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

Это действительно решает мою первоначальную проблему, заключающуюся в том, что мои данные легче поддерживать в Firebase, поскольку все данные хранятся в элементах, а не дублируются в профилях пользователей. Спасибо Неизменным и Переселект в Реакте. Они созданы для этого материала. Надеюсь, что это помогает кому-то еще. Поймите, что сначала это было немного широко для стека, надеюсь, код поможет уточнить вариант использования и сделать его ценным для других сейчас.

И в последний раз. Мои данные теперь выглядят так в Firebase.

Пункты

-items
 --id1
   theData
 --id2
   theData
 --id3
   theData
 --id4
   theData      

UserProfile

-itemSelected
 ---UserA
    ---Id1  (different than item key)
       "id": "id1KeyFromItems"
    ---Id2  (different than item key)
       "id": "id3KeyFromItems"
  ---UserB
    ---Id1 (different than item key)
       "id": "id1KeyFromItems"
    ---Id2 (different than item key)
       "id": "id4KeyFromItems"

Мои высокоуровневые функции БД всегда создают новые уникальные ключи в firebase. Я не хотел менять это только для этого решения. Это работает, и все работает одинаково для CRUD в моем приложении.

0 голосов
/ 26 июня 2018

Многое зависит от того, как именно вы будете использовать данные. Я бы сказал, что большая часть вашей структуры верна. Единственное, что я хотел бы сделать, это не дублировать данные в itemSelected/{userId}. Просто установите для фактического itemId значение true, если оно выбрано.

-itemSelected
  -UserA
    -Id1 (same as items Id1): true
    -Id2 (same as items Id2): true

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

Что касается комментария «подмножества» о данных, хранящихся в itemSelected: если вы имеете в виду, что данные конкретного элемента являются подмножеством данных, хранящихся для этого элемента в таблице items, и которые предназначены для безопасность (т. е. некоторые данные в разделе items не должны быть видны пользователю), тогда я бы предложил оставить все как есть, а просто создать функцию Firebase для сохранения согласованности записей "в конечном итоге".

...