0

I'm trying to work out the data model for my first Firebase project. As many others, I'm struggling to figure out the best way to model my data.

I have a list of phrases that contain sounds. Each phrase can have many sounds, but a sound can be part of many phrases.

The user will be viewing phrase data and then go "deeper" and view each individual sound associated with the current phrase. One sound per page.

So far, I've got a 4 node solution:

phrases: {
  phraseKey1: {
    //  ... phrase data
  },
  phraseKey2: {
    // ... phrase data
  }
}

sounds: {
  soundKey1: {
    // ... sound data
  },
  soundKey2: {
    // ... sound data
  },
  soundKey3: {
    // ... sound data
  }
}

soundsPerPhrase: {
  phraseKey1: {
    soundKey1: true,
    soundKey2: true
  },
  phraseKey2: {
    soundKey3: true,
    soundKey2: true
  }
}

phrasesPerSound: {
  soundKey1: {
    phraseKey1: true
  },
  soundKey2: {
    phraseKey1: true,
    phraseKey2: true
  },
  soundKey3: {
    phraseKey2: true
  }
}

From reading other posts like this one and a udemy course I see that this could work well. However, my specific need is that the sounds in each phrase be in a specific order.

Would it be better to duplicate the sound entry for each phrase? Because in each phrase it could be in a different position? I know I can run a query and order the results by a certain property, but this would be a custom order known only the author.

Or is there another, better way to model the data for my needs?

I need to be able to look up the sounds for the current phrase. And then in another area of the app, look up the phrases in which the sound is present.

I'm kind of at a brick wall.

Thanks in advance for your time.

Alex B
  • 1,009
  • 3
  • 18
  • 26

1 Answers1

1

my specific need is that the sounds in each phrase be in a specific order

In that case you can keep a value for each sound in a phrase:

soundsPerPhrase: {
  phraseKey1: {
    soundKey1: 1,
    soundKey2: 2
  },
  phraseKey2: {
    soundKey3: 1,
    soundKey2: 2
  }
}

Would it be better to duplicate the sound entry for each phrase?

That is always a consideration. I usually see developers duplicating data if they read it a lot more than it gets written/modified.

The trade-off here is read performance vs write performance. If you duplicate the data reading it will be faster (and simpler), since you need to read from fewer locations. On the other hand, writing the data will be slower (and more complex), since you're writing to multiple locations.

Note that these are just things to consider. There is no singular best data model. In NoSQL databases the data model typically evolves with your set of use-cases, and with your experience/comfort level with NoSQL models.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thank you Frank. The solution of putting the order as the value in the association node is a very good one. I will be reading far more than reading, at least for the foreseeable future. – Alex B Apr 18 '18 at 10:48
  • Perhaps in the phrasesPerSound association I could use the same technique and so keep the order of the sound in the phrase against the phraseKey. `soundKey1: { phraseKey1: 2, phraseKey2: 3 }`. – Alex B Apr 18 '18 at 10:50