With Firebase(NoSQL) you don't need to know your schema beforehand; BUT you need to know your queries, which is way more difficult. Bye bye easy and real-time analytics. Let's admit it people, SQL was good and it worked well so far.
With SQL, proper planning of your app and schema gives amazing results. I understand that SELECT using multiple joins can get complicated and may incur a slow response time but you also ensure that your data is consistent and some front end developer doesn't load your DB with garbage.
Not only that... for doing something like #8 you need to think in advance all your possible queries, if not, you'll need to make a cron task to update all the data, duplicate that way and then make the query, it's a stupid idea.
Query #4: What if I need something like "SELECT * FROM Users WHERE Name LIKE '%ab%'? Query #8 is REALLY scary, what if I need Users with age > 20 and location = 'Berlin'? What about a screen where the user can have a unlimited number of filtering the results? should I duplicate all the possibilities and transform the DB in a monster?
8 лет назад+1
In some video they said That duplicates in Firebase are not bad. Same as in other NoSQL. But it's harder to manage later.
The indexing trick at the end of the video seems to be general enough to be part of the database functionality. These DIY things are what scare me as a Firebase noob.
Indeed #8 cannot be called a "fix"! its a freaking patch poorly done.... WHAT IF i need to check 3 or more conditions? Do i have to create triplet "indexes"? WHAT IF i have a db with 1 billion entries? Do i have to "index" all entries for all possible combinations of queries? This looks absurd #askfirebase
Hi David, I have 2 further questions regarding your last query: a) Don't u think your index is kinda redundant? If Alice moved from Berlin, Is there a way we can set a rule to automatically update our indexes without altering existing insertions? b) Let's say we have 1M recoreds, how can we add 1M indexes fast? #Askfirebase
no. 8 looks hackish. hopefully soon we don't have to create things like age_location else the database will grow like hell. just imagine i have to deal with this on every item without assistance. prone to errors.
eg. i have to update age, with this structure i also need to retrieve location just so i can update age_location. what if one of the developers forgot to update age_location? i understand that we can simply abstract this using third party js libraries, but that's another story.
that's a good approach, however it is applicable only if we're dealing with small data. as far as i know the advantage of putting age_location is the ability to set it as index so firebase can query it faster. but yeah it seems if we have more than 2 WHERE conditions, i think it is better to query the first condition and the rest of the filters on the client side.
So instead of having to be so constricted by an SQL schema, all you have to do in Firebase is have elements for every possible combination of elements in your database! So much easier!
I also think #8 is a no go with this scary thing until the right approach. may be you should cover more of those queries come up with something that is practically possible.
Best of your 8 part series so far. customerList: AngularFireList ; this.customerList = this.angularFireDatabase.list('customers', ref => ref.limitToFirst(2));
Good job on explaining basics queries, it's good to see Firebase team made an effort for explaining how simple queries can be made using Firebase SDK. However, for number 8 (combined queries), I really hope Firebase comes up with something like Parse Compound Query.. My current solution for combining query is to manually parse them on the client side. This is indeed inefficient, but making new attributes just to satisfies combined query is just awful.
Although I dont think there is a way to do this directly with Firebase yet.. i do know if you use something like angular you can pull all the data and then perform a pipe filter/search before displaying to the user in the view. Typically the JSON is small so the impact on the network is pretty minimal if you do it right
The last one killed Firebase for me. Something as simple as a query with 2 clauses cannot be impossible to do. What you did, changing the schema is surreal. What if you have 100 users? what if you have millions? You cannot possibly think that preddict the questions when building your data is doable. This renders something as common as multi filter in forms impossible. I was kinda going for the flexibility of NoSQL but so far your videos only taught me that NoSQL has more complex data structure, more complex and limited code to access it, and the only advantage I see is that changing the schema is easy, but that is not the problem with SQL. Creating a table takes 5min. Populating it another 10min. Why is this such a problem? I dont understand NoSQL permise.
Number #8 is a deal breaker... you say in the first video the advantage of NoSQL is I don't need to care about the schema at the start. But now you say I need to care about every single field permutation I might want in the future? What if 2 years into a lifecycle of an app users start to want to filter by 2 fields, with SQL I just slap a 'Where x and y' query under a button and I'm done, with this I need to somehow go over the entire DB file and create new keys?! Then there is the extra storage overhead on the server and performance degradation by comparing ever larger strings.
Man that last hack just shows that Firebase is not quite ready for prime time. Love the concept but it needs more functionality (like count and aggregations). Hopefully it will be there soon.
Thinking about how to deal with #8 in a more tidy way (speaking of iOS but it should work with any platform) what if you get the results that match one of the conditions (age 28) and then on the client (iOS, Android, Web) refine that query for instance with an NSPredicate in iOS (looking for the ones that live in Berlin). So you get one broad set from the firebase and then on the client you refine that set to your needs. What do you guys think? Drawbacks? #Askfirebase
Come on. 8 was a total cop-out. We'll never know with certainty what queries we may need in the future. There's got to be a better way. Having said all that, thank you for the other parts; they were helpful.
I think I understand limitToFirst and limitToLast, but say I had 1000 results and I wanted to paginate them, how would I limit to 50 at a time (kind of like how gmail does)? Or would I have to pull in the whole set? Cheers
#8 is a step back. What if there are multiple AND in the WHERE statement? What if I change the age, then I also have to change the age_location, etc, etc.
It really feels like Firebase and Angular are thought up by IT hipsters without a proper computer science education. I mean, creating a reduntant attribute that will be hard to maintain, just to be able to make a query that involves more than one attribute... so you're telling me THIS is somehow the future, and more convenient than SQL? Give me a break, this is 2017, not 1977. Similarly, Angular transports us 15 years back and introduces spaghetti code 2.0, nice job. I'm starting to lose hope for Google if they don't step up their game and start learning from history.
Jeez, repeating data in order to create new indexes, so stupid, in the end your data will be full of trash and confuse to read. Anyway, despite the fact that SQL, in the end, is A LOT easier to read/write/use, it doesn't make sense to "teach" SQL users how to use Firebase, because basically they shouldn't use Firebase. If they do, they will be switching from a working project with SQL to a No-SQL project, and these projects should definitely not be the same, or, you have a big problem with your project scope.
Anyone knows if the number #8 has a better way to work when it's necessary to make query like: "Select * from users where Location like 'B%' && age>30" ..... This way on the video it's terrible! Unfortunately i think the best way is filter on client
Thank you for the video. This was helpful. It would be great if the sample built during the video could be posted. It would make it easier for people who have seen to video to experiment further.
Well, you can create a dynamic query reference, like const ref = (age, loc) => rootRef.child('users').orderByChild('age_location').equalTo(`${age}_${loc})
The last query it's almost an insult and shouldn't be here. So, I need to think my data structure for the queries I MAY HAVE in the future???? That's crap! How many times should I need to duplicate data with a crappy structure? And with 3 or more relations? Wow... Parse did one excellent job and Firebase can't even handle it.
i have 2 users Customer and Worker whenever customer books a worker for work the worker will get option to accept or decline and when customer books a work i store in firebase as "key"="bookingtimedateprogress" and its "value"="28-08-2019 01:30 AM Accepted/Declined" here i need to fetch data that startAt(time) and contains="Accepted" query1 = FirebaseDatabase.getInstance().getReference().child("App Data").child("Booking").child(userID).orderByChild("bookingtimedateprogress").startAt(currenttime)..... ??? How can i user contains even with startAt
Really man, so we now need to pre-decide what queries we would need before structuring our database. And what if we miss one query and have our json structure already decided, is it really worth to change the json structure to accomodate just one query, that's making the developer's life hell, fix it man.
I know this is an old video, but I don't see the question asked in the comments anywhere. Once you have: (#8) const eightRef = rootRef.child('users').orderByChild('age').equalTo('28') cant you just make a new query on the eightRef you just created to get only people out of it that live in Berlin? along the lines of: nineRef = eightRef('users').orderByChild('location').equalTo('Berlin')
For those of you who got let down by #8, maybe Firestore, a NoSQL cloud database from the same firebase team, will offer some hopes. Here is a snapshot of Firestore's querying capability: var citiesRef = db.collection("cities"); citiesRef.where("state", "==", "CA") citiesRef.where("state", "==", "CA").where("population", "
That last query seem won't go well. To use the query, do I have to add the custom age_location entry to every record in the database? What if my database has been in use for long and I need to use a new query like that e.g. when there's an update to my app where I need to add a new query view? Do I then need to go and edit every record in the database and add the custom entry field as shown in this video?
Everything was perfect except #8. totally destroyed the flow.. No way I am going to create such strange keys, in this case, please be open, you create one ref and then another ref inside to get specific data.
If you want to stick with Firebase environment, you should check out the Firestore. But, it isn't designed for fast data updates, for each document. The limit is around 1 change per second, per doc. A doc, is like a node of data. An user data, as example.
Hello David, i have a question for you. Is there a way to simulate a "WHERE IN" on FRD? Something like "SELECTE * FROM table WHERE value IN ('val1', 'val2', 'val5')"
how could I make a voluntary consultation on firebase? "UPDATE table set field = field + 1 where field2 LIKE '% DATA%"? in case I want to update with +1 all the records that contain DATA at the beginning, middle or end of the field.
If I have understood this video, then Firebase is awful. Let's assume I want to do a query equal to: "select * from users where name = 'David' order by dateCreated" Would I be right in saying that this is IMPOSSIBLE with Firebase (because we are forced to orderBy the thing that we are filtering)? If that's the case then it's really REALLY bad. Can somebody please tell me that I've misunderstood this.
The last case is not handled efficiently on NOSQL, because suppose we have to select based on ten different fields, which will somehow change, it will be hard to create several data combinations for all cases...
filter it at client side, if you are doing paging, and there is not enough result for the page, query another set filter out david, if there is extra for next page, hold it.
Question about age_location: I understand the need as a realtime NoSql database and scalability to create the combined field. Is there a way to create it from the console in batch for all the registers?
How to make a select "select count(*) from users where age>30" which return 1000+ records. If I get these objects and count from client side, it may cost a lot of bandwidth. So any solution on this case
well, right now they had added "functions" that can work automatically when new data shows up on the firebase database, that can count "server side" (is just a js method inside a nodejs heroku-style server from firebase) into a new variable/string object of your JSON
this one was really helpfull. thank you very much. is there a video about how to prewent children in the firebase with the same data, for example, i don't want to push to firebase if the email is already in the database,in other words, if there is a user with that email？
For everyone worrying about #8: Firebase's new Firestore has composite indexes to solve these. Check out from minute 10: ruclips.net/video/Ofux_4c94FI/видео.html
so what happens when you use firebase to try and retrieve data that doesnt exist? like if you queried for some random email addresss thats not present in the data??
I was hoping he'd just say "JUST KIDDING" after doing #8. Holy Hack!!!
saadazzz that was saad azzz cloudy day in berlin
LMAO!
Do explain? Wow #8 jeeese, and it is != && in the WHERE clause it is "AND" :P
was thinking to use firebase but query 8 left an impression "WTF" what was that
@@ToddKerpelmanCorp please can you give us a link? Or can you drop the query syntax here?
Please help out.
Packing up. Going back to SQL
😁😁
😂😂😂😂
Sql is easy and consistent across all DB, sounds good to me 😂
8. Query - End of my short journey with firebase
😁 same here
lol yeah
With Firebase(NoSQL) you don't need to know your schema beforehand; BUT you need to know your queries, which is way more difficult. Bye bye easy and real-time analytics. Let's admit it people, SQL was good and it worked well so far.
It's feels like we are going 20 years back... Like old pre-database on text files again... But this time with websocket for real time :P
With SQL, proper planning of your app and schema gives amazing results. I understand that SELECT using multiple joins can get complicated and may incur a slow response time but you also ensure that your data is consistent and some front end developer doesn't load your DB with garbage.
oooh man number 8 looks awful
that's what I thought!
It was dissapointing :)
shouldn't their DB be bothering about indexes rather than us adding "indexes" as data? I have not seen any sane developer doing this to his own DB!
He shouldn't even show the last one... now I'm mad.
After the number 8 I feel dirty, I need to get a shower, AWFUL!
8. ruined it
not going to use it until there's a way to check multiple equal values.
Yeah, how would you have to query everybody that is older than 28 and living in Berlin? That must be a pain to figure out.
it is trust me. im having a very hard time
Everything is difficult if you are not familiar with it. This helped me with multiple where :
www.firebase.com/docs/web/guide/retrieving-data.html
@@dcsMagazine link not found
Still to this day it would kill me. You have to type more too 😬
Come on David, #8 is a pure hack! As far as I experienced, queries are the worst part of the Firebase.. I wish you guys could improve that soon.
Not only that... for doing something like #8 you need to think in advance all your possible queries, if not, you'll need to make a cron task to update all the data, duplicate that way and then make the query, it's a stupid idea.
It's the end of 2020 and there is no fix for that. Goodbye firebase
@@スヘア Solved in Firestore
Query #4: What if I need something like "SELECT * FROM Users WHERE Name LIKE '%ab%'?
Query #8 is REALLY scary, what if I need Users with age > 20 and location = 'Berlin'? What about a screen where the user can have a unlimited number of filtering the results? should I duplicate all the possibilities and transform the DB in a monster?
In some video they said That duplicates in Firebase are not bad. Same as in other NoSQL. But it's harder to manage later.
Lograste hacer la Query #4 con firebase?
I was about to ask the same thing. Did you ever find an answer?
Believe it or not, some people don't speak English. Weird! Right?
also trying to figure query #4
The indexing trick at the end of the video seems to be general enough to be part of the database functionality. These DIY things are what scare me as a Firebase noob.
Indeed #8 cannot be called a "fix"! its a freaking patch poorly done.... WHAT IF i need to check 3 or more conditions? Do i have to create triplet "indexes"? WHAT IF i have a db with 1 billion entries? Do i have to "index" all entries for all possible combinations of queries?
This looks absurd #askfirebase
did you solve it?
Can you tell me if you know the answere😥
Does 8 just mean that I have to go through ALL of my 3 million users every day, calculate their age and update the age_location index?
Hmm working with the Firebase Database seems to be a lot harder compared to the other one...
#8 impossible to deal with, seems still pretty in beta stage to do such kind of hack...Hope they could make it neat soon
bro, i have bad news for you
@@fajrulalam5046 yes i know
Hi David, I have 2 further questions regarding your last query: a) Don't u think your index is kinda redundant? If Alice moved from Berlin, Is there a way we can set a rule to automatically update our indexes without altering existing insertions? b) Let's say we have 1M recoreds, how can we add 1M indexes fast? #Askfirebase
#8 You may not sort ages in any order, if you specify a location ( users who are 20 - 40 yr's old, and are living in Madagascar) Marvellous work
no. 8 looks hackish. hopefully soon we don't have to create things like age_location else the database will grow like hell. just imagine i have to deal with this on every item without assistance. prone to errors.
eg. i have to update age, with this structure i also need to retrieve location just so i can update age_location. what if one of the developers forgot to update age_location?
i understand that we can simply abstract this using third party js libraries, but that's another story.
that's a good approach, however it is applicable only if we're dealing with small data. as far as i know the advantage of putting age_location is the ability to set it as index so firebase can query it faster.
but yeah it seems if we have more than 2 WHERE conditions, i think it is better to query the first condition and the rest of the filters on the client side.
I agree, number eight needs a work around, what's happen if you have a more than two select and the user start combining values ???
I guess #8 leaves us with many client side things to be handled if the query gets really big. ☠
So instead of having to be so constricted by an SQL schema, all you have to do in Firebase is have elements for every possible combination of elements in your database! So much easier!
They need to add the ability to query by multiple filters, like: ?age=24&name="sally"&location="Boston"
age_name_location according to this young man... that's a dumb move from Google.
Tentei fazer isso ai e não deu certo. Não filtra corretamente
#8 just killed my enthusiasm. I've had the impression Firebase was a limited Data Management system, now it looks like a fancy key-value store.
I also think #8 is a no go with this scary thing until the right approach. may be you should cover more of those queries come up with something that is practically possible.
did you solve it?
8th answer was a deal breaker :(
Best of your 8 part series so far.
customerList: AngularFireList ;
this.customerList = this.angularFireDatabase.list('customers', ref => ref.limitToFirst(2));
Good job on explaining basics queries, it's good to see Firebase team made an effort for explaining how simple queries can be made using Firebase SDK. However, for number 8 (combined queries), I really hope Firebase comes up with something like Parse Compound Query.. My current solution for combining query is to manually parse them on the client side. This is indeed inefficient, but making new attributes just to satisfies combined query is just awful.
8 just doesn't seem right. Is there no other way to query when there are conditions on 2 different children?
I too have the same question.
It has to have another way, I can't believe on it
did you solve it?
Sql queries do not use && syntax for AND. they use the full word.
Select * from Users where age = 28 and location = "Berlin"
Are you new to SQL?
Of course you can use && instead of AND
You can also use || instead or OR
You can also negate values with ! instead of NOT
It was all looking great util 8. That was painful
Something tells me developers are going to have a feature request that translates SQL to firebase commands
You could put a cause with OR:
SELECT * FROM Users WHERE Location = "Berlin" OR Age = 28;
I think you'll have to do that manually downloading the whole data...
What if the query question goes like this:
Get all users who are above 18 and live in Berlin.
Going to read the docs more thoroughly, but I came here for the comments regarding #8!
what if i wanted to find people who are between 20 and 50 who live in berlin
Maybe: .orderByChild("age_location").startAt("20_Berlin").endAt("50_Berlin")
Peter Siegmund how about people between 20 and 50 who live in berlin or sf :)
Rey Guerrero That would be harder. I don't know. #askfirebase
@Peter
that not work like that, because 21_SF is with string ordering between 20_Berlin and 50_Berlin
yeah lol
How to make a select "Where name like '%a%'"?
Would like to know this too. For a search function to work would be cool to have this functionality
I think that it is impossible. I see some people using elastic search for this.
I think too... and using foreach
So does this elastic aearch work when offline? Not
Although I dont think there is a way to do this directly with Firebase yet.. i do know if you use something like angular you can pull all the data and then perform a pipe filter/search before displaying to the user in the view. Typically the JSON is small so the impact on the network is pretty minimal if you do it right
The last one killed Firebase for me.
Something as simple as a query with 2 clauses cannot be impossible to do.
What you did, changing the schema is surreal. What if you have 100 users? what if you have millions?
You cannot possibly think that preddict the questions when building your data is doable.
This renders something as common as multi filter in forms impossible.
I was kinda going for the flexibility of NoSQL but so far your videos only taught me that NoSQL has more complex data structure, more complex and limited code to access it, and the only advantage I see is that changing the schema is easy, but that is not the problem with SQL. Creating a table takes 5min. Populating it another 10min. Why is this such a problem?
I dont understand NoSQL permise.
I don't think any professional would use this after looking at #8. SQL is still king after that. Wish it could be better
Number #8 is a deal breaker... you say in the first video the advantage of NoSQL is I don't need to care about the schema at the start. But now you say I need to care about every single field permutation I might want in the future? What if 2 years into a lifecycle of an app users start to want to filter by 2 fields, with SQL I just slap a 'Where x and y' query under a button and I'm done, with this I need to somehow go over the entire DB file and create new keys?! Then there is the extra storage overhead on the server and performance degradation by comparing ever larger strings.
i hope this quering is getting improve :) nice work firebase!
Man that last hack just shows that Firebase is not quite ready for prime time. Love the concept but it needs more functionality (like count and aggregations). Hopefully it will be there soon.
I thought I was dump when i figured out how to do multiple querying like the guy did. Well not anymore
Thanks so much for this video. I was looking for something just like this. Appreciate it!
Thinking about how to deal with #8 in a more tidy way (speaking of iOS but it should work with any platform) what if you get the results that match one of the conditions (age 28) and then on the client (iOS, Android, Web) refine that query for instance with an NSPredicate in iOS (looking for the ones that live in Berlin).
So you get one broad set from the firebase and then on the client you refine that set to your needs. What do you guys think? Drawbacks? #Askfirebase
Come on. 8 was a total cop-out. We'll never know with certainty what queries we may need in the future. There's got to be a better way. Having said all that, thank you for the other parts; they were helpful.
I think I understand limitToFirst and limitToLast, but say I had 1000 results and I wanted to paginate them, how would I limit to 50 at a time (kind of like how gmail does)? Or would I have to pull in the whole set? Cheers
Is Javascript you have to write one hundred lines of codes to achieve that.
#8 is a step back. What if there are multiple AND in the WHERE statement? What if I change the age, then I also have to change the age_location, etc, etc.
#8 is a killer... Is this still the case? Or is there an update.? don't want to read the documention right now...
Excellent very useful for the LearnByExample people.
Text Editor he is using = Visual Studio Code
The best editor javascript i've tried
It really feels like Firebase and Angular are thought up by IT hipsters without a proper computer science education. I mean, creating a reduntant attribute that will be hard to maintain, just to be able to make a query that involves more than one attribute... so you're telling me THIS is somehow the future, and more convenient than SQL? Give me a break, this is 2017, not 1977. Similarly, Angular transports us 15 years back and introduces spaghetti code 2.0, nice job. I'm starting to lose hope for Google if they don't step up their game and start learning from history.
This is one of the most helpful tutorials I found yet! Thanks!!
Jeez, repeating data in order to create new indexes, so stupid, in the end your data will be full of trash and confuse to read. Anyway, despite the fact that SQL, in the end, is A LOT easier to read/write/use, it doesn't make sense to "teach" SQL users how to use Firebase, because basically they shouldn't use Firebase. If they do, they will be switching from a working project with SQL to a No-SQL project, and these projects should definitely not be the same, or, you have a big problem with your project scope.
What should I do when I want to get data with more combinations like (age_lacation) query. Every time i go and change my schema😥. #askfirebase
Anyone knows if the number #8 has a better way to work when it's necessary to make query like:
"Select * from users where Location like 'B%' && age>30" .....
This way on the video it's terrible! Unfortunately i think the best way is filter on client
You could create location_age and do: rootRef.child('users').orderByChild('location_age').startAt('Berlin_31');
Keep up the good work
Thank you for the video. This was helpful. It would be great if the sample built during the video could be posted. It would make it easier for people who have seen to video to experiment further.
There is still no better way to make the number 8? could you answer me please
haha such a funny channel, love this content!!! woohoo
Thanks so much!!
And if one minute later we need make request: age 30 and location is Berlin... and then: age 25 and location is London?
Well, you can create a dynamic query reference, like const ref = (age, loc) => rootRef.child('users').orderByChild('age_location').equalTo(`${age}_${loc})
What's the point of having a scalable / large data object when you can't even filter on it. SAD! ;)
The last query it's almost an insult and shouldn't be here. So, I need to think my data structure for the queries I MAY HAVE in the future???? That's crap! How many times should I need to duplicate data with a crappy structure? And with 3 or more relations? Wow... Parse did one excellent job and Firebase can't even handle it.
When you get the users back do they return as JSON files? How would I obtain a certain attribute from a user that I get as a result of my query?
i have 2 users Customer and Worker
whenever customer books a worker for work the worker will get option to accept or decline
and when customer books a work i store in firebase as "key"="bookingtimedateprogress" and its "value"="28-08-2019 01:30 AM Accepted/Declined"
here i need to fetch data that startAt(time) and contains="Accepted"
query1 = FirebaseDatabase.getInstance().getReference().child("App Data").child("Booking").child(userID).orderByChild("bookingtimedateprogress").startAt(currenttime)..... ???
How can i user contains even with startAt
Great video! Would be even better if this video was referenced in firebase documentation.
How can i do a sql with a rage of dates
Like between 12/12/2012 and 12/12/2013
Really man, so we now need to pre-decide what queries we would need before structuring our database. And what if we miss one query and have our json structure already decided, is it really worth to change the json structure to accomodate just one query, that's making the developer's life hell, fix it man.
excellent query firebase course
I know this is an old video, but I don't see the question asked in the comments anywhere.
Once you have: (#8)
const eightRef = rootRef.child('users').orderByChild('age').equalTo('28')
cant you just make a new query on the eightRef you just created to get only people out of it that live in Berlin?
along the lines of:
nineRef = eightRef('users').orderByChild('location').equalTo('Berlin')
8) Alternatively, with Firestore we have usersRef.where("age", "==", "28").where("location", "==", "berlin")
funny
For those of you who got let down by #8, maybe Firestore, a NoSQL cloud database from the same firebase team, will offer some hopes.
Here is a snapshot of Firestore's querying capability:
var citiesRef = db.collection("cities");
citiesRef.where("state", "==", "CA")
citiesRef.where("state", "==", "CA").where("population", "
How can I can do an aggregation (OR) on firebase ? For example Select from Users where name = 'example1' or name='example2'? Thank you.
That last query seem won't go well. To use the query, do I have to add the custom age_location entry to every record in the database?
What if my database has been in use for long and I need to use a new query like that e.g. when there's an update to my app where I need to add a new query view? Do I then need to go and edit every record in the database and add the custom entry field as shown in this video?
Are these queries still up to date as of September 2018???
did you solve it?
Everything was perfect except #8. totally destroyed the flow.. No way I am going to create such strange keys, in this case, please be open, you create one ref and then another ref inside to get specific data.
Does it get any better about the 8th query in 2020?
Nope.
If you want to stick with Firebase environment, you should check out the Firestore. But, it isn't designed for fast data updates, for each document. The limit is around 1 change per second, per doc. A doc, is like a node of data. An user data, as example.
Lord have mercy RE:#8. Something that is expressed clearly and doesn't mean making a mess of your data in SQL, is butchered in Firebase/NoSql. *sigh*.
Hope u can fix poin 8..
Hello David, i have a question for you. Is there a way to simulate a "WHERE IN" on FRD? Something like "SELECTE * FROM table WHERE value IN ('val1', 'val2', 'val5')"
totally helpful!
Very Helpful video. How to you do a Select with an OR???
how could I make a voluntary consultation on firebase? "UPDATE table set field = field + 1 where field2 LIKE '% DATA%"? in case I want to update with +1 all the records that contain DATA at the beginning, middle or end of the field.
If I have understood this video, then Firebase is awful.
Let's assume I want to do a query equal to:
"select * from users where name = 'David' order by dateCreated"
Would I be right in saying that this is IMPOSSIBLE with Firebase (because we are forced to orderBy the thing that we are filtering)? If that's the case then it's really REALLY bad. Can somebody please tell me that I've misunderstood this.
How can we get age > 20 and location 'Berlin'
maybe orderByChild('location_age').startAt('Berlin_21')
The last case is not handled efficiently on NOSQL, because suppose we have to select based on ten different fields, which will somehow change, it will be hard to create several data combinations for all cases...
Tried to sneak in #8 and hoped we didn't notice ;)
How would you a negative queries? Select everyone that is not 'david'?
filter it at client side, if you are doing paging, and there is not enough result for the page, query another set filter out david, if there is extra for next page, hold it.
Question about age_location: I understand the need as a realtime NoSql database and scalability to create the combined field. Is there a way to create it from the console in batch for all the registers?
why not just admit that firebase can't handle chained conditions
What about "less than" for float? Just placing 49.9999 isn't practical
what's the diff. between orderbyChild vs orderbyvalue. When do we use orderbyValue()
writing this on March 2019, is Firebase still doing that horrible thing for query #8?
The limit is cool. Is there a start at or start after?
How to make a select "select count(*) from users where age>30" which return 1000+ records. If I get these objects and count from client side, it may cost a lot of bandwidth. So any solution on this case
Dumb question, once I have one of these references, how do I actually see the data?
how to transform COUNT in sql ?
SELECT COUNT(USER_ID) from USERS WHERE USER_ID = UID;
That cannot scale well can it?
Oh boy, that is sacrificing a lot for how cool firebase is.
well, right now they had added "functions" that can work automatically when new data shows up on the firebase database, that can count "server side" (is just a js method inside a nodejs heroku-style server from firebase) into a new variable/string object of your JSON
it could process with javascript array, but the answer that query is 1. user only have 1 UID... :-)
Firebase needs to do something about number 8 type queries.
Is that really the best practice to get age and location??
What is i build a dynamic data analysis app?
I had to learn firebase, then I watched tutorial videos... until this #8... And I quit my job!
Query #4: What if I need something like "SELECT * FROM Users WHERE Name LIKE '%ab%'?
have you found any solution yet?
this one was really helpfull. thank you very much. is there a video about how to prewent children in the firebase with the same data, for example, i don't want to push to firebase if the email is already in the database,in other words, if there is a user with that email？
For everyone worrying about #8: Firebase's new Firestore has composite indexes to solve these.
Check out from minute 10: ruclips.net/video/Ofux_4c94FI/видео.html
so what happens when you use firebase to try and retrieve data that doesnt exist? like if you queried for some random email addresss thats not present in the data??
super cool
How can I filter by field and timestamp? E.g.: Last inserted question (timestamp) from the "Company" poll.