1

I'm interested in the new firebase.util package that allows you to join data (paths) and how I might be able to continue modeling with UML as I have become accustomed to over many years. I can see how easy it might be to make one-to-many relationships in this way. And because firebase is hierachical, component relationships are just very natural.

Aggregate relationships can be duck'd as we're all accustomed to this in javascript - enforcing aggregate relationship doesn't seem to me to be a barrier to modeling successful projects using firebase...

My question is if anyone has experimented | had success with | can show examples of how it might be possible to represent many-to-many relationships, perhaps by joining the join paths themselves.

If I don't get much interest in the question I may post my own trial-error results...

Thanks

Reinsbrain
  • 2,235
  • 2
  • 23
  • 35
  • The question is very open ended, perhaps if you had a specific example of an instance where you want to model a many-to-may relationship, we could help? – Anant Jan 03 '14 at 19:31
  • An example of many-to-many relationship is groups and members.. Eg. a person can be a member of many groups, and a group may have many members. – Reinsbrain Jan 04 '14 at 23:52
  • Sorry Anant, Further research has led me to believe that although joins are a powerful new feature for firebase and have many great new uses, a many-to-many relationship for data in firebase is not possible at this time without duplicating data (if the requirement is bi-directional). My thought was that I might be able to separate relations into a separate object and traverse the relations using joins. Yes you can do that with joins but it is uni-directional. To make it bi-directional we'll need some form of reference type (beyond primitives, arrays, and objects) which is not object literal. – Reinsbrain Jan 06 '14 at 19:52
  • And, we would need ability to have multiple keys... – Reinsbrain Jan 06 '14 at 19:53
  • i tried to join a snapshot returned from a join to another reference ... it didn't work for me and I expect it is not supposed to... – Reinsbrain Jan 06 '14 at 20:15
  • 2
    Yes, you are right - many-to-many relationships require the data to be denormalized, there's more info in these blog posts: https://www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html https://www.firebase.com/blog/2013-10-01-queries-part-one.html and https://www.firebase.com/blog/2014-01-02-queries-part-two.html – Anant Jan 06 '14 at 23:55

1 Answers1

0

I have tried to use composite key. For example, user can be member of many rooms. We need two queries: List of room members, and list of user's rooms. So we can have only one collection rooms-users, where key is built like this:

id = [roomId, userId].join()

The truth is, I'm not sure whether it is a good pattern. It seems it can prevent security rules settings https://stackoverflow.com/a/17431390/233902 and maybe even have performance implications.

So maybe two or even more collections are required. Two for many to many, third for relation metadata. As I'm thinking about, collections should be optimized for queries, so composite key is anti-pattern for Firebase.

Community
  • 1
  • 1
Daniel Steigerwald
  • 1,075
  • 1
  • 9
  • 19