Hi all, I'm relatively new to noSQL databases, and Firebase is different even from those. I recently completed a server-side web development course at my university, where I built a simple budgeting application on the LAMP stack. I've been looking into Firebase because I like that it's well-supported, and I like that I can have a web app and an android app that use the same data source. So I've taken up making this budgeting application with all by business logic in javascript (instead of php) and my data in Firebase (instead of mySQL). The problem that I'm running into though is what the best way to structure my data is. Here's what my structure looks like in a relational database:
+---------------------+
| User |
+---------------------+
| id |
+---------------------+
| email |
+---------------------+
| password hash |
+--------------------+
+-------------------------+
| Category |
+-------------------------+
| id |
+-------------------------+
| user_id |
+-------------------------+
| name |
+-------------------------+
| last_refresh (date) |
+-------------------------+
| amount (money) |
+-------------------------+
+--------------------------+
| Transaction |
+--------------------------+
| id |
+--------------------------+
| category_id |
+--------------------------+
| amount (money) |
+--------------------------+
| date |
+--------------------------+
| comments |
+--------------------------+
The idea of this application is that each user owns a collection of categories, and each category has a collection of transactions that belong to it. With relational databases, it was easy to look at the category's last_refresh date (the day the budget resets for the month), and get all the transactions in that category that took place after that date. This way, the user can see their balances for each category as they are right now. Then when the last_refresh date is more than a month in the past, it is moved up a month, and the same thing can be done.
After some thought, I decided to structure my Firebase data like this (this particular user only has one category, but you could have more):
"users" : {
"GUID" : {
"categories" : {
"Groceries" : {
"amount" : 25000,
"refreshCode" : 0,
"lastRefresh" : "YY-MM-DD",
"transactions" : {
"GUID" : {
"amount" : 2002,
"date" : "YY-MM-DD",
"comment" : "Delicious apples"
},
"GUID" : {
"amount" : 20303,
"date" : "YY-MM-DD",
"coment" : "blah blah blah"
}
}
}
}
}
}
"GUID" is the uid for the user, and is just some generated value for the transactions (one is assigned when I call push()). I couldn't think of a meaningful unique key to use for transactions (comments could be the same, dates could be the same, amounts could be the same).
This structure allows me to get the user object on the main page. From there, I have all of the user's categories, and all of the transactions in that category. The only concern that I have is that I need to get all of the user's categories, but I only want a subset of the transactions under each category. This was easy in a RDBMS, but the only way to do this in Firebase I can think of is to have checks in my business logic (javascript) that checks the transaction date against the category's refresh date. But my computer architecture knowledge says that I should avoid "if" statements if possible (since they are expensive with modern pipelining processors). The only other solution that I can think of is that every time I change the refresh date, I move the old transactions to a new location, and then I can just use all of the transactions.
So I guess my question(s) : Is there a design pattern to handle this type of problem? Should I just be ok with checking every transaction in my business logic? Is this just a bad problem to apply Firebase to? Am I missing something important in the Firebase SDK that I can take advantage of to overcome this problem?
Thanks so much, for reading. Any advice is appreciated!
-Justin