So I'm creating this flutter project where I want to match 2 field from a different collection in firebase how should I do that? Like if the first data from the 1st field matches the data from the 2nd field return true
here it the example image
- and here is the 2nd example image
Firestore queries can only order/filter on data that is inside each document that they actually return. There is no way to order/filter in any value in another document, whether present in the results or not.
Usually you'll want to modify your data model to your use-case, typically by adding more data that allows this specific query. This is actually quite common in NoSQL databases, where you often end up expanding your data model to allow for specific use-cases. To learn more about data modeling in NoSQL databases, I recommend reading NoSQL data modeling and watching Todd's video series Get to know Cloud Firestore.
Related
i am trying to display all this shops inventory data and filter by category/name/price/etc..
i can do this by using orderbyChild("Shop") and push all data in
to list and display/filter data but with large user data that
way can cause performance?
is their better way to get all this shops data and filter using
category /product name/price/etc...
Firebase Realtime Database queries look for values at a fixed path under each direct child node of the path that you query. They don't recursively search on all nodes under there. So, if you want to search across all shops, you'll have to (possibly additionally) store the data in a flat list.
Also see Firebase Query Double Nested
I am trying to build a database with Cloud Firestore and having read the documentation about hierarchic structure I have found another solution to the one present in the documentation example.
I have a collection of categories, and each category can have subcategories. Whereas I could use the system provided in the Firestore documentation example such as collection/document/subcollection/document... I have found another example for MongoDB where instead of having subcollections it uses nested data in a single document with parent-child relations as described in the image below
What approach is better if I want the user to be able to see all the subcategories so the user can categorize a certain event? By better I mean in terms of avoiding multiple connections to the DB (as this is what Firestore prices with).
This document discusses nested data and its tradeoffs, "Choose a Data Structure". I'm not sure that the statement about multiple connections for pricing is correct. Firestore charges for number of operations, storage, and network bandwidth.
If all users share a single categories list, you would be able to retrieve the entire list with one operation with your current structure. Note that there is a 1 MiB limit for document size.
This question pertains to good practice rather than a specific use case.
I have the choice to either save information in Mongo documents and then display it to the user or perform mongo queries based on a partial selection of this information to get the rest I need to display.
To clarify, for example, either I could store 10 fields in a document and then display all these fields or perform mongo queries based on 6 of the fields to get the rest.
In one case, the database becomes larger but the loading might be faster and in the other case, the database is smaller but the loading is probably faster
Which one of these options should I choose?
It depends on preference and use case.
Consider this picture:
The book says documents store database struggle with highly connected domains because "relationships between aggregates aren’t firstclass citizens in the data model, most aggregate stores furnish only the insides of aggregates with structure, in the form of nested maps.
".
And besides: "Instead, the application that uses the database must build relationships from these flat, disconnected data structures."
I'm sorry, I don't understand what does it mean. Why documents store database struggle with a context based on highly relationships?
Because document stores do not support joins. Each time you need to get more data it is a separate query. Instead, document stores support the idea of nesting data within documents.
So just a quick best practice question here. How do I know when I should create new collections in MongoDB?
I have an app that queries TV show data. Should each show have its own collection, or should they all be store within one collection with relevant data in the same document. Please explain why you chose the approach you did. (I'm still very new to MongoDB. I'm used to MySql.)
The Two Most Popular Approaches to Schema Design in MongoDB
Embed data into documents and store them in a single collection.
Normalize data across multiple collections.
Embedding Data
There are several reasons why MongoDB doesn't support joins across collections, and I won't get into all of them here. But the main reason why we don't need joins is because we can embed relevant data into a single hierarchical JSON document. We can think of it as pre-joining the data before we store it. In the relational database world, this amounts to denormalizing our data. In MongoDB, this is about the most routine thing we can do.
Normalizing Data
Even though MongoDB doesn't support joins, we can still store related data across multiple collections and still get to it all, albeit in a round about way. This requires us to store a reference to a key from one collection inside another collection. It sounds similar to relational databases, but MongoDB doesn't enforce any of key constraints for us like most relational databases do. Enforcing key constraints is left entirely up to us. We're good enough to manage it though, right?
Accessing all related data in this way means we're required to make at least one query for every collection the data is stored across. It's up to each of us to decide if we can live with that.
When to Embed Data
Embed data when that embedded data will be accessed at the same time as the rest of the document. Pre-joining data that is frequently used together reduces the amount of code we have to write to query across multiple collections. It also reduces the number of round trips to the server.
Embed data when that embedded data only pertains to that single document. Like most rules, we need to give this some thought before blindly following it. If we're storing an address for a user, we don't need to create a separate collection to store addresses just because the user might have a roommate with the same address. Remember, we're not normalizing here, so duplicating data to some degree is ok.
Embed data when you need "transaction-like" writes. Prior to v4.0, MongoDB did not support transactions, though it does guarantee that a single document write is atomic. It'll write the document or it won't. Writes across multiple collections could not be made atomic, and update anomalies could occur for how many ever number of scenarios we can imagine. This is no longer the case since v4.0, however it is still more typical to denormalize data to avoid the need for transactions.
When to Normalize Data
Normalize data when data that applies to many documents changes frequently. So here we're talking about "one to many" relationships. If we have a large number of documents that have a city field with the value "New York" and all of a sudden the city of New York decides to change its name to "New-New York", well then we have to update a lot of documents. Got anomalies? In cases like this where we suspect other cities will follow suit and change their name, then we'd be better off creating a cities collection containing a single document for each city.
Normalize data when data grows frequently. When documents grow, they have to be moved on disk. If we're embedding data that frequently grows beyond its allotted space, that document will have to be moved often. Since these documents are bigger each time they're moved, the process only grows more complex and won't get any better over time. By normalizing those embedded parts that grow frequently, we eliminate the need for the entire document to be moved.
Normalize data when the document is expected to grow larger than 16MB. Documents have a 16MB limit in MongoDB. That's just the way things are. We should start breaking them up into multiple collections if we ever approach that limit.
The Most Important Consideration to Schema Design in MongoDB is...
How our applications access and use data. This requires us to think? Uhg! What data is used together? What data is used mostly as read-only? What data is written to frequently? Let your applications data access patterns drive your schema, not the other way around.
The scope you've described is definitely not too much for "one collection". In fact, being able to store everything in a single place is the whole point of a MongoDB collection.
For the most part, you don't want to be thinking about querying across combined tables as you would in SQL. Unlike in SQL, MongoDB lets you avoid thinking in terms of "JOINs"--in fact MongoDB doesn't even support them natively.
See this slideshare:
http://www.slideshare.net/mongodb/migrating-from-rdbms-to-mongodb?related=1
Specifically look at slides 24 onward. Note how a MongoDB schema is meant to replace the multi-table schemas customary to SQL and RDBMS.
In MongoDB a single document holds all information regarding a record. All records are stored in a single collection.
Also see this question:
MongoDB query multiple collections at once