Using mongodb and waterline, how can I query a collection taking in count a relationship with other?
For example, let's say I have two collections, Employer and Employee. An employer can have one or more employees. How could I get a list of employers based in a property of an employee, like getting the list of employers that have employees with an age above of 25 years.
I know that could be done with two queries specifying the required parameters, but I wonder if that could be done in one query, like mysql using joins.
Thanks for your time.
No. MongoDB does not support joins so if you need if your data is not embedded in a single collection you will need to use two queries to achieve the result you want
Related
Can anyone tell me if it is possible to search multiple collections at once in Firebase?
What I need to do is search the data in both the 2009 and 2010 collections in bio_data (more collections will need to be added in the future) and extract the document from one of them.
Or it doesn't matter if there is a way to get a name list of the collections inside a document
Firestore does not have the concept of server-side joins or projections across collections. Each query or document read can only take data from a single collection, or from all collections that have the same name with collection group queries.
If you need to load data from two collections, you'll need at least two reads.
For a better understanding I highly recommend watching the Get to know Cloud Firestore playlist.
Michel's answer is correct.
In addition, I would suggest a change to your data model: Instead of having one sub-collection per year, you could have one unique sub-collection and add a year field to the docs in this unique collection.
This way it would be easy to query by year: For one year, for several years with the in operator (up to 10 equality (==) clauses) or for all the years.
And with a Collection Group query you could even query all the data for all the students.
I'm not good at documents DB, wanna improve myself.
The task is: to store an enterprise hierarchy into Mongo DB.
There are employers and departments. Every employer belongs to a particular department ( BTW what if someone belongs to multiple departments?). Sure, there is employees hierarchy: Director is a root. So everyone except director has a direct boss ( what if someone has multiple bosses which are not from the same branch?)
The structure could be changed ( lets say not more often than once per a day) and has a timestamp.
So how to store it into Mongo DB? Multiple collection? Or one collection and many documents?
All viable ideas are appreciated.
Store each employee as a single document. In that document store an array of departments and an array of direct reports. ICs have a direct reports array that is empty. Index the reports array so queries are efficient.
This structure supports multiple departments per employee and multiple managers per employee.
Most hierarchies change atomically so I would suggest changes be applied to a new collection and that collection replace the old collection.
You can use the MongoDB $graphLookup operator to query the graph of employees.
I want to move customer surveys for different products and survey types into mongodb.
A product can have multiple survey types.
The existing data consists of about 2 million surveys and growing.
There will be a need of querying the data for stats and reports and the structure of the surveys and their questions can change over time. Which means that the documents wont always be the same.
What will suite the best:
One big collection with product_id and type overhead within one db
Multiple collections per product and type within one db
Or a mix of multiple dbs and collections for product and type
I read about advantages and disadvantages and also that every case has its own solution that suits the usage and purpose.
Unfortunately, I'm not sure what applies the best for my case.
It all depends on how you will access you data, it is by customer, survey or product?.
You can make a product collection and put the surveys as an array of subdocuments or you can make a customer collection and do the same thing.
It is not something we can help you with here without knowing the details of the business requirement.
Just keep in mind, MongoDB is schemaless and how you will design your documents and collections depends on how you will access your data.
Lets say i have two collections
The Family Collection
{"Name":"Steven", "Children":[{"Name":"Liv", "Children":[{"Name":"Milo"}] },{"Name":"Mia"},{"Name":"Chelsea"}]}
And the movie collection
{"Movie":"Rush Hour 3", "Actors":["Jackie","Mia"]}
{"Movie":"LOTR", "Actors":["Viggo","Liv"]}
Now i need a query to find the names of the family members that's not actors. The result should contain Steven, Milo and Chelsea.
You would have to do this "yourself" in your application logic. Mongo doesnt do joins. So essentially, your current collections are structured similar to relational independent tables -- in mongo, you would have to redesign your schema so that your query is possible (or , like I said, do it in the app)
Assuming I have data of high school students across the country. Each high school data are not related each other and also never needed to be related to each other (compartmentalized). Which one is recommended if I use mongoDB:
1) Create single collection inheritance with the following attributes:
high_school_id, student_id, name, address
2) Create multiple collections (possibly thousands) with the following attributes:
student_id, name, address
The name of collection will follow school_data_<X> format, where X is the high_school_id. So, to query, my program can dynamically construct the collection name.
I came from MySQL, PostgreSQL background where having thousands tables are not common (So, option (1) is far more makes sense). How is it in MongoDB?
I recommend you use the first option, because MongoDB has a limit on the number of collections. More about this read docs.
You may want to consider a third option: create a collection with the students, where each student's record will include a high school data. There is nothing wrong in the duplication of data, you should not thinking about this in MongoDB, but you should thinking about more convenient way working with data.