CODEWITHSUNDEEP
firebasedata-structuresfirebase-realtime-databasenosql
khusrav
khusrav

Reputation: 5307

Firebase data structure and url to use

I'm really new to firebase, want to try out a simple mix-client app on it - android, js. I have a users table and a tasks table. The very first question that comes to my mind is, how to store them (and thus how the url to be)? For example, based on the tasks table, should I use:

  1. /tasks/{userid}/task1, /tasks/{userid}/task2, ...

Or

  1. /{userid}/tasks/task1, /{userid}/tasks/task2, ...

The next question, based on the answer to the first one - why to use any of the versions?

In my opinion, the first version is good because domains are separated. The second approach is good because data is stored per-user which may make some of the operations easier.

Any ideas/suggestions?

Update: For the current case, let's say there are following features:

Simple operations.

Upvotes: 0

Views: 156

Answers (1)

yonga springfield
yonga springfield

Reputation: 714

This answer might come in late, but here's how I feel about the question after a year's experience with Firebase.

  1. For your very first question, it totally depends on which data your application will mostly read and how and in which order ( kind of like sorting ) you expect to read the data.

your first proposal of data structure, that is "/tasks/{userid}/task1", "taks/{userid}/task2"... is good if the application will oftentimes read the tasks as per users with an added advantage of possibly sorting the data by any task's "attribute" if I might call it so.

say each task has got a priority attribute then,

  // get all of a user's tasks with a priority of 25.
  var userTasksRef = firebase.database().ref("tasks/${auth.uid}");
  userTasksRef.orderByChild("priority").equalTo(25).on(
    "desired_event",
    (snapshot) => {
      //do something important here.
  });

2. I'll highly advice against the second approach because generally most if not all of the data that is associated to that user will be stored under the "/{userid}/" node and with firebase's mechanism, should a situation be in which you need more than one datum at that path level, it will require you getting that data with all the other data that's associated to that user's node ( tasks and any other data included). I won't want that behavior on my database. Nonetheless, this approach still permits you to store the tasks as per the users or making multiple RESTfull requesting and collecting the required data datum after datum. Suggest fanning out the data structure if this situation is encountered. Totally valid data structure if there don't exist a use case in the application where in datum at the first level of the path is needed and only that datum is needed but rather the block of data available at that path level with all the data at the deriving paths at that level( that is 2nd 3rd ... levels).

As per the use cases you've described, and if the database structure you've given is exhaustive of your database structure, I'll say it isn't enough to cover your use cases. Suggest reading the docs here. Great and exhaustive documentation of their's.

As a pick, the first approach is a better approach to modelling this data use case in NoSQL and more accurately Firebase's NoSQL database.

Upvotes: 1

Related Questions