Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Structuring Relationships in Firebase

I've got two items in my Firebase: providers and services, and I'm trying to figure out the best way to structure and build relationships using Firebase's recommended flattened architecture approach.

My data looks something like this:

{
  "services" : {
    "hip_replacement" : {
      "title" : "Hip Replacement"
    }
  },

  "providers" : {
    "the_blue_hospital" : {
      "title" : "The Blue Hospital"
    }
  }
}

I would like to link these two items together so that if you were to visit the Hip Replacement page, The Blue Hospital would show up underneath it, if you were to visit The Blue Hospital page, Hip Replacement would show up underneath that. A two-way relationship, essentially.

What would be the best way to structure something like this? I was thinking along the following lines:

{
  "services": {
    "hip_replacement": {
      "title": "Hip Replacement",
      "providers": {
        "the_blue_hospital": true,
        "the_red_hospital": true
      }
    },
    ...
  },
  "providers": {
    "the_blue_hospital": {
      "title": "The Blue Hospital",
    },
    "the_red_hospital": {...
    },
    "the_green_hospital": {...
    }
  }
}

Is there a better way to achieve this or a more elegant solution? Any help is appreciated.

Thanks in advance!

like image 434
realph Avatar asked Jan 12 '15 15:01

realph


People also ask

How do you create a one to many relationship in Firebase?

Each Job can contain many Items and one Item must be contained by a single job (Simple One to Many). My present database structure is that both Item and Job are top level lists in firebase and each Item contains the jobKey to which it belongs. This allows me to find all items in a job as long as I know the job key.

Can Firebase be relational database?

Simple answer is NO , you cant. But eventually if you are very good with the NoSQL database system that firebase provides you can perform same tasks on both the database. As said before firebase uses NOSQL database . It uses json object to be precise.

Does Firebase have schema?

Firebase security rules, this video does an amazing job explaining them, are a way in which you can sort of create schemas. An important consideration when using these rules is that if you're using the Firestore Admin SDK (used for backend code) then your rules will be bypassed.


1 Answers

The problem with joined data in Firebase is that you optimize for certain read or update use cases at the expense of others. In your sample above, creating or deleting a relationship between services and providers requires two separate updates to each "table". There's really nothing wrong with that, but it's not the only way to go.

For a modestly sized data set, you could have a "join table" that maps services to providers, similar to what might be done in the relational DB world. The data might look something like this:

{
  "services": {
    "hip_replacement": {}
  },
  "providers": {
    "the_blue_hospital": {...},
    "the_red_hospital": {...},
    "the_green_hospital": {...}
  },
  "serviceProviders": {
    "-JqD5JX0RUDTXsu7Ok3R": {
      "provider": "the_blue_hospital",
      "service": "hip_replacement"
  }
    "-JqDoKfyJqPkQlCXDvFM": {
      "provider": "the_green_hospital",
      "service": "hip_replacement"
  }
    "-JbE7Ji_JRz2bHgBdMWQ": {
      "provider": "the_blue_hospital",
      "service": "hip_replacement"
  }
}

There are pros and cons of this approach:

Pro

  • Easy to add mappings in one place
  • Easy to delete mappings in one place
  • Flexible options to reformat the data for display, beyond the context of a single provider or service, such as an index.

Con

  • You have load the whole data set. Firebase doesn't let you filter within a key, clients have to load the whole list, then filter in memory. I suspect this will work fine for hundreds of records, anyways, maybe for low thousands.
  • You have to do some client work to filter the list for display and merge it with the actual service and provider data. Again, if the data set isn't too big, underscore/lodash groupBy() can make short work of this.

You should consider:

  • How much updating and deleting will you do?
  • Is the join information really that simple? Would you need more records (display names, prices, etc.) that make maintenance on the join table more complicated than I suggested?
like image 132
James Avatar answered Oct 17 '22 20:10

James