4 ms·
From this post I can tell you’re not really understanding how Firebase is supposed to be used, which is fine. For you it’s better to use the traditional approac
by endisneigh 3y ago
From this post I can tell you’re not really understanding how Firebase is supposed to be used, which is fine. For you it’s better to use the traditional approach with database and app server.
And yes, there is such a thing as relational data. If you do not believe this then you really shouldn’t use Firebase (or dynamodb for that matter).
- quickthrower2 3y agoI know I am holding it wrong etc! But I really tried in earnest, as a fanboy of firebase, for quite a long time. The problems I had were with basic things. You have companies, a company can have many users, users might belong to more than one company (hello Slack...) and then there can be relationship between users. Putting aside the problem between chair & keyboard. Another difference is more if you make a mistake in your relational schema, you can SQL your way out of it - add an extra join or group by. And you can also fairly easily migrate you way out of it to a new schema that is the right structure. This requires actual code with firebase, and a lot of patience, and probably a lot more downtime. So you need more of a waterfall approach, I would suggest, to design a schema ahead of time, and know all of your requirements. NoSQL document-oriented schemas just aren't flexible (unless the DB supports something like materialized views to help you get out of it)