MongoDB Collection Structure
up vote
0
down vote
favorite
I have a collection named User.
User has many information that can be grouped together example:
{address : {street:"xx", city:"xx"}}
{history: {school:"xx", job: "xx"}}
{..}
So I want to know what the best practice is
1. First way, Using nested fields:
{user:
{address : {street:"xx", city:"xx"}}
{history: {school:"xx", job: "xx"}}
{..}
}
2. Second way: Just put them all together.
{user:
street:"xx",
city:"xx",
...
school:"xx",
job: "xx",
...
}
First way is obviously more readable for humans and it makes it easier for human to find relevant information.
What are the downside to grouping/nesting data like the first way?
Does it make querying of nested fields slower? Indexing issues? Any idea?
mongodb mongodb-query spring-data-mongodb
asked Nov 11 at 4:23
user1955934
242321
add a comment |
up vote
0
down vote
favorite
I have a collection named User.
User has many information that can be grouped together example:
{address : {street:"xx", city:"xx"}}
{history: {school:"xx", job: "xx"}}
{..}
So I want to know what the best practice is
1. First way, Using nested fields:
{user:
{address : {street:"xx", city:"xx"}}
{history: {school:"xx", job: "xx"}}
{..}
}
2. Second way: Just put them all together.
{user:
street:"xx",
city:"xx",
...
school:"xx",
job: "xx",
...
}
First way is obviously more readable for humans and it makes it easier for human to find relevant information.
What are the downside to grouping/nesting data like the first way?
Does it make querying of nested fields slower? Indexing issues? Any idea?
mongodb mongodb-query spring-data-mongodb
asked Nov 11 at 4:23
user1955934
242321
mongodb is not OODB, so it is not designed to store objects, even though it is possible. what benefit do you get from storing "address" as an object that contains street and city? it would be much easier to store it the 2nd way, flatten, so queries can be simpler.
– OhadR
Nov 11 at 8:44
i guess it's more readable the first way. Information can be grouped accordingly, reading relevant data is easier. But is there any performance downside?
– user1955934
Nov 11 at 9:59
Possible duplicate of Is there any performance difference for nested document in mongodb query
– OhadR
Nov 11 at 10:25
Right, yes i want to confirm the answer was no difference?
– user1955934
Nov 11 at 10:40
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a collection named User.
User has many information that can be grouped together example:
{address : {street:"xx", city:"xx"}}
{history: {school:"xx", job: "xx"}}
{..}
So I want to know what the best practice is
1. First way, Using nested fields:
{user:
{address : {street:"xx", city:"xx"}}
{history: {school:"xx", job: "xx"}}
{..}
}
2. Second way: Just put them all together.
{user:
street:"xx",
city:"xx",
...
school:"xx",
job: "xx",
...
}
First way is obviously more readable for humans and it makes it easier for human to find relevant information.
What are the downside to grouping/nesting data like the first way?
Does it make querying of nested fields slower? Indexing issues? Any idea?
mongodb mongodb-query spring-data-mongodb
asked Nov 11 at 4:23
user1955934
242321
I have a collection named User.
User has many information that can be grouped together example:
{address : {street:"xx", city:"xx"}}
{history: {school:"xx", job: "xx"}}
{..}
So I want to know what the best practice is
1. First way, Using nested fields:
{user:
{address : {street:"xx", city:"xx"}}
{history: {school:"xx", job: "xx"}}
{..}
}
2. Second way: Just put them all together.
{user:
street:"xx",
city:"xx",
...
school:"xx",
job: "xx",
...
}
First way is obviously more readable for humans and it makes it easier for human to find relevant information.
What are the downside to grouping/nesting data like the first way?
Does it make querying of nested fields slower? Indexing issues? Any idea?
mongodb mongodb-query spring-data-mongodb
mongodb mongodb-query spring-data-mongodb
asked Nov 11 at 4:23
user1955934
242321
asked Nov 11 at 4:23
user1955934
242321
edited Nov 11 at 10:22
asked Nov 11 at 4:23
user1955934
242321
asked Nov 11 at 4:23
user1955934
242321
asked Nov 11 at 4:23
user1955934
242321
242321
mongodb is not OODB, so it is not designed to store objects, even though it is possible. what benefit do you get from storing "address" as an object that contains street and city? it would be much easier to store it the 2nd way, flatten, so queries can be simpler.
– OhadR
Nov 11 at 8:44
i guess it's more readable the first way. Information can be grouped accordingly, reading relevant data is easier. But is there any performance downside?
– user1955934
Nov 11 at 9:59
Possible duplicate of Is there any performance difference for nested document in mongodb query
– OhadR
Nov 11 at 10:25
Right, yes i want to confirm the answer was no difference?
– user1955934
Nov 11 at 10:40
add a comment |
mongodb is not OODB, so it is not designed to store objects, even though it is possible. what benefit do you get from storing "address" as an object that contains street and city? it would be much easier to store it the 2nd way, flatten, so queries can be simpler.
– OhadR
Nov 11 at 8:44
i guess it's more readable the first way. Information can be grouped accordingly, reading relevant data is easier. But is there any performance downside?
– user1955934
Nov 11 at 9:59
Possible duplicate of Is there any performance difference for nested document in mongodb query
– OhadR
Nov 11 at 10:25
Right, yes i want to confirm the answer was no difference?
– user1955934
Nov 11 at 10:40
mongodb is not OODB, so it is not designed to store objects, even though it is possible. what benefit do you get from storing "address" as an object that contains street and city? it would be much easier to store it the 2nd way, flatten, so queries can be simpler.
– OhadR
Nov 11 at 8:44
mongodb is not OODB, so it is not designed to store objects, even though it is possible. what benefit do you get from storing "address" as an object that contains street and city? it would be much easier to store it the 2nd way, flatten, so queries can be simpler.
– OhadR
Nov 11 at 8:44
i guess it's more readable the first way. Information can be grouped accordingly, reading relevant data is easier. But is there any performance downside?
– user1955934
Nov 11 at 9:59
i guess it's more readable the first way. Information can be grouped accordingly, reading relevant data is easier. But is there any performance downside?
– user1955934
Nov 11 at 9:59
Possible duplicate of Is there any performance difference for nested document in mongodb query
– OhadR
Nov 11 at 10:25
Possible duplicate of Is there any performance difference for nested document in mongodb query
– OhadR
Nov 11 at 10:25
Right, yes i want to confirm the answer was no difference?
– user1955934
Nov 11 at 10:40
Right, yes i want to confirm the answer was no difference?
– user1955934
Nov 11 at 10:40
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
If you store the extra data under the user, it enables faster reading and writing of entire user document.
If you the extra data under separate collections, it may enable faster access find/update of that data (depending on your indexes). MongoDB does enable indexing fields in arrays
My suggestion is to try and list your common data access use cases, create a test database with a LOT of mock data, then test performances using queries and aggregations to defer between the different storage modelling options.
answered Nov 11 at 10:14
Danny Varod
13.2k44787
So the first way i mentioned in my question, does not involve using separate collections nor array. I just structure it as a nested fields. Would this make queries/indexing for those fields that are nested?
– user1955934
Nov 11 at 10:19
@user1955934 Not sure what you meant in your comment, however, querying is possible on nested info, less straightforward though. Also, I highly recommend you check out the aggregation API. Also, don't forget the explain option on queries.
– Danny Varod
Nov 12 at 11:41
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
If you store the extra data under the user, it enables faster reading and writing of entire user document.
If you the extra data under separate collections, it may enable faster access find/update of that data (depending on your indexes). MongoDB does enable indexing fields in arrays
My suggestion is to try and list your common data access use cases, create a test database with a LOT of mock data, then test performances using queries and aggregations to defer between the different storage modelling options.
answered Nov 11 at 10:14
Danny Varod
13.2k44787
So the first way i mentioned in my question, does not involve using separate collections nor array. I just structure it as a nested fields. Would this make queries/indexing for those fields that are nested?
– user1955934
Nov 11 at 10:19
@user1955934 Not sure what you meant in your comment, however, querying is possible on nested info, less straightforward though. Also, I highly recommend you check out the aggregation API. Also, don't forget the explain option on queries.
– Danny Varod
Nov 12 at 11:41
add a comment |
up vote
1
down vote
If you store the extra data under the user, it enables faster reading and writing of entire user document.
If you the extra data under separate collections, it may enable faster access find/update of that data (depending on your indexes). MongoDB does enable indexing fields in arrays
My suggestion is to try and list your common data access use cases, create a test database with a LOT of mock data, then test performances using queries and aggregations to defer between the different storage modelling options.
answered Nov 11 at 10:14
Danny Varod
13.2k44787
So the first way i mentioned in my question, does not involve using separate collections nor array. I just structure it as a nested fields. Would this make queries/indexing for those fields that are nested?
– user1955934
Nov 11 at 10:19
@user1955934 Not sure what you meant in your comment, however, querying is possible on nested info, less straightforward though. Also, I highly recommend you check out the aggregation API. Also, don't forget the explain option on queries.
– Danny Varod
Nov 12 at 11:41
add a comment |
up vote
1
down vote
up vote
1
down vote
If you store the extra data under the user, it enables faster reading and writing of entire user document.
If you the extra data under separate collections, it may enable faster access find/update of that data (depending on your indexes). MongoDB does enable indexing fields in arrays
My suggestion is to try and list your common data access use cases, create a test database with a LOT of mock data, then test performances using queries and aggregations to defer between the different storage modelling options.
answered Nov 11 at 10:14
Danny Varod
13.2k44787
If you store the extra data under the user, it enables faster reading and writing of entire user document.
If you the extra data under separate collections, it may enable faster access find/update of that data (depending on your indexes). MongoDB does enable indexing fields in arrays
My suggestion is to try and list your common data access use cases, create a test database with a LOT of mock data, then test performances using queries and aggregations to defer between the different storage modelling options.
answered Nov 11 at 10:14
Danny Varod
13.2k44787
answered Nov 11 at 10:14
Danny Varod
13.2k44787
answered Nov 11 at 10:14
Danny Varod
13.2k44787
answered Nov 11 at 10:14
Danny Varod
13.2k44787
13.2k44787
So the first way i mentioned in my question, does not involve using separate collections nor array. I just structure it as a nested fields. Would this make queries/indexing for those fields that are nested?
– user1955934
Nov 11 at 10:19
@user1955934 Not sure what you meant in your comment, however, querying is possible on nested info, less straightforward though. Also, I highly recommend you check out the aggregation API. Also, don't forget the explain option on queries.
– Danny Varod
Nov 12 at 11:41
add a comment |
So the first way i mentioned in my question, does not involve using separate collections nor array. I just structure it as a nested fields. Would this make queries/indexing for those fields that are nested?
– user1955934
Nov 11 at 10:19
@user1955934 Not sure what you meant in your comment, however, querying is possible on nested info, less straightforward though. Also, I highly recommend you check out the aggregation API. Also, don't forget the explain option on queries.
– Danny Varod
Nov 12 at 11:41
So the first way i mentioned in my question, does not involve using separate collections nor array. I just structure it as a nested fields. Would this make queries/indexing for those fields that are nested?
– user1955934
Nov 11 at 10:19
So the first way i mentioned in my question, does not involve using separate collections nor array. I just structure it as a nested fields. Would this make queries/indexing for those fields that are nested?
– user1955934
Nov 11 at 10:19
@user1955934 Not sure what you meant in your comment, however, querying is possible on nested info, less straightforward though. Also, I highly recommend you check out the aggregation API. Also, don't forget the explain option on queries.
– Danny Varod
Nov 12 at 11:41
@user1955934 Not sure what you meant in your comment, however, querying is possible on nested info, less straightforward though. Also, I highly recommend you check out the aggregation API. Also, don't forget the explain option on queries.
– Danny Varod
Nov 12 at 11:41
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53245820%2fmongodb-collection-structure%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
mongodb is not OODB, so it is not designed to store objects, even though it is possible. what benefit do you get from storing "address" as an object that contains street and city? it would be much easier to store it the 2nd way, flatten, so queries can be simpler.
– OhadR
Nov 11 at 8:44
i guess it's more readable the first way. Information can be grouped accordingly, reading relevant data is easier. But is there any performance downside?
– user1955934
Nov 11 at 9:59
Possible duplicate of Is there any performance difference for nested document in mongodb query
– OhadR
Nov 11 at 10:25
Right, yes i want to confirm the answer was no difference?
– user1955934
Nov 11 at 10:40