I want to store the comma separated ids on a child node & how can I filter data as in sql we can use IN clause to fetch data any possibility in firebase to perform this kind of operation in firebase database.
Please suggest any possible solution for this.
Firebase Realtime Database doesn't have the equivalent of SQLs IN clause. It also doesn't have a way to find a substring in a value. So the data model you are looking to use, doesn't allow the use-case you want. As usual with NoSQL databases, the solution is to pick a data model that does allow your use-case..
The most likely cause I know for the structure you describe is to associate the child node with a bunch of categories. If that is your case, read my answer here for a proper data structure: Firebase query if child of child contains a value
This is one of the cases where the new Cloud Firestore database offers better querying support, since it recently added a feature to efficiently test if an array contains a certain value (video). If you're only just getting started with your project, you might want to check if Firestore is a better fit for your use-cases.
Related
I have a firestore collection with a bunch of documents, each with plenty subfields. On a web page I need a list of a specific subfields from each document.
Currently I load the the entire database when you load the page and then loop through and get the wanted values. This uses way to many reads to get very little data.
Is there a way to solve this e.g. a autogenerated a collection that contains field from other collection in an array or something.
Many thanks in advance
Auto-creating such a subcollection with just the fields you need is a great way to reduce the bandwidth needed to load the data.
There is nothing built into Firestore to create those derived documents, but it's fairly easy to build something using Cloud Functions. Create a function that responds to a Firestore onWrite trigger, and write the subset of the data to its destination there. It's common to have a separate Cloud Function for each such use-case, and I regularly see projects with 100+ such functions.
I expect we'll also start seeing Firebase Extensions for this type of thing, but right now no-one seems to have built one.
I have a table with a thousand records in it and I want to do a google like search full-text/fuzzy search.
I read about MySQL v8's Full-Text search and let's say we don't have that functionality yet.
There is this JavaScript library called Fuse.js that do fuzzy-search which is what I need.
I can combine it by creating a API that returns the table data in JSON format and then pass it to Fuse.js to do a fuzzy-search.
Now, I think it's not recommended to load all data from table every time someone wants to search.
I read about Redis, and the first thing that came in my mind is to save all table data in Redis using JSON.stringify and just call it every time instead of querying the database. Then whenever a data is added in the table, I will also update the contents of the data in Redis.
Is there a better way to do this?
That is a very common caching pattern.
If you need a more efficient way to store and retrieve your JSON to/from Redis you might want to consider one of the available Redis Modules.
e.g.
RedisJSON allows you to efficiently store, retrieve, project (jsonpath) and update in place.
RediSearch allows you to have full text search over Redis Hash and efficiently retrieve data according to the user's query.
Last
RedisJSON2 (aka RedisDoc) combines both modules above, meaning efficient JSON store and retrieve with Full Text support
I have a dilemma on how to solve possible redundant data querying.
I am using MongoDB with Apollo server and client. My MongoDB has several collections of data. The main collection consists of IDs pointing to supporting collections.
I am not sure about how to solve the mapping of IDs of my main collection to supporting collections IDs to retrieve the actual values. The thing is that mostly I already have data of supporting collections cached in Apollo client cache.
Do you think I should only query the IDs in my main collection and map IDs to values on the frontend using cached data? Or should I have a resolver that takes IDs in main collection, makes database queries to supporting collections to get value for each ID and then sends prepared data to frontend?
I appreciate any insight! Thank you.
As always, it depends. I assume that this is your setup, with a main collection.
type OtherDoc {
id: String
field: String
}
type MainDoc {
id: String
otherDocs(param: String): [OtherDoc]
}
type Query {
mainDocs: [MainDoc]
}
In such case, querying for mainDocs { id otherDocs("...") { id field } } is definitely a natural way to get this data. It might be redundant, in terms of getting OtherDoc when different param result in the same docs. If so, you may think about querying only their IDs and then querying for separate docs, if the client doesn't have them.
I'd say it's a valid solution, but definitely not something you should consider from the beginning. This optimization will definitely limit the bandwidth, but increase the number of requests. What is more, you don't know when to actually refetch OtherDoc. Well, maybe you do, but you have to think about and build it, where without you have it out-of-the-box.
A different approach, a more cache-friendly one, may change the schema to limit such situations, where your data overlap. This is not always possible due to the business logic, but worth considering if it is.
I have been using C# to run operations on a DocumentDB instance and really like it so far. I have a lot of C# code that queries from multiple collections to create new collections from the relationships between the first two collections.
Can I essentially move my logic up to the server in stored procedures? I tried answering this question for myself, but all I could find was documentation on how to acquire the collection associated with the stored procedure. So then I thought, could I call a stored procedure that called another stored procedure, passing in the first collection?
Is there any way I can refer to multiple collections in a stored procedure somehow?
Would it be easier to find an easier way to know what belongs to each "collection" if I store everything in the same collection?
Stored procedures run inside of a single collection (or a single partition in a partitioned collection). A call to a stored procedure can only operate on the data in that collection/partition.
When I see this question asked, I usually wonder if you are thinking of collections as a direct analog to tables from the SQL world or even the use of the word "collection" from the MongoDB world. In DocumentDB it's best to not separate your data up by type but rather to mix data of different types in the same collection and separate along some other scale out boundary like tenant, user, geography, etc. If you do that, as long as your stored procedure doesn't need to cross that tenant, user, or geography boundary, it'll be able to provide you with fully ACID cross-document transactions.
I'm using Meteor JS for a project so inherently I'm using MongoDB. I'm storing a user's check in and out actions. I'm currently storing them as individual docs in the collection. Each action contains 3 fields; in or out, time of action and userid. Is the best way to go though? Should I just have one doc per members and then store each action in an array? Is there another way? I anticipate several hundred members, but hopefully several thousands of members in the future. Thanks.
From experience, I can say that storing records instead of arrays is a better choice in the long run.
As far as Meteor is concerned, its reactivity handles collection records, but not individual fields in arrays. In other words, if one element gets added to the checkins array of a user object, the entire user object needs to be synchronized with the clients. If you store records instead, only the newly added record will be sent by the publication.
As far as MongoDB is concerned, there is a document size limit of 16MB. Not sure how frequent your checkins and checkouts are, but if you store them in an array, you might run into that limitation at some point.
Records are also easier to access than arrays.
For more details, see MongoDB data modeling and Database modeling in Bulletproof Meteor.