3 ms·

I'm still struggling to understand how embedded documents can be useful in Mongo, considering there is no way to do a SELECT with a WHERE clause on their conten

by zwass 15y ago

I'm still struggling to understand how embedded documents can be useful in Mongo, considering there is no way to do a SELECT with a WHERE clause on their contents. https://jira.mongodb.org/browse/SERVER-142 https://jira.mongodb.org/browse/SERVER-142 . The age of this bug report has me wondering whether there is some fundamental design flaw with a schemaless database that causes this. Thoughts?

matan_a 15y ago
Well, Mongo does support queries on embedded objects as described in http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching+into+Objects%29 http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching... It might not be exactly what you were looking for, but it could have the same outcome.
stevenspasbo 15y ago
I'm currently working on an Android app, and started looking at couchdb a few days ago. I have to say I'm pretty intrigued, but I'm going to be dealing with location data, so the lack of querying has put me off for now.
latch 15y ago
Embedded documents currently serve a smaller purpose that one would assume at first glance. I answer a lot of questions in the MongoDB-User group by telling people to "pull it into its own collection". However, there are a couple planned features that'll change this. Virtual collections is one, but the other is the $ operator in field selection..which I believe is planned for 2.1. Even as-is though, they are useful. The tag example is simplistic...let me give you a real case from mogade.com. We have a scores collection, which looks something like: { _id: ObjectId('...'), leaderboard: ObjectId('...'), user: 'leto', daily: { points: 100, data: 'level 10', date: ...., }, weekly: { points: 150, data: 'level 8', date: ...., }, overall: { points: 300, data: 'level 15', date: ...., } } We essentially store the user's top score for each scope (daily, weekly and overall). You could store a scope-per-document, which is how it initially was....but, that isn't how it's modeled and, it takes a lot more space (user and leaderboard get repeated 3x, along with the index which is on those two fields). Also, I wrote about collections vs embedded documents: http://mongly.com/Multiple-Collections-Versus-Embedded-Documents/ http://mongly.com/Multiple-Collections-Versus-Embedded-Docum... Edit: I wouldn't rely on the age of a feature request as a sign that there's something fundamentally wrong with a design. Not everything can be top priority.

by zwass 15y ago

matan_a 15y ago

Well, Mongo does support queries on embedded objects as described in http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching+into+Objects%29 http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching... It might not be exactly what you were looking for, but it could have the same outcome.

stevenspasbo 15y ago

I'm currently working on an Android app, and started looking at couchdb a few days ago. I have to say I'm pretty intrigued, but I'm going to be dealing with location data, so the lack of querying has put me off for now.

latch 15y ago

Embedded documents currently serve a smaller purpose that one would assume at first glance. I answer a lot of questions in the MongoDB-User group by telling people to "pull it into its own collection". However, there are a couple planned features that'll change this. Virtual collections is one, but the other is the $ operator in field selection..which I believe is planned for 2.1. Even as-is though, they are useful. The tag example is simplistic...let me give you a real case from mogade.com. We have a scores collection, which looks something like: { _id: ObjectId('...'), leaderboard: ObjectId('...'), user: 'leto', daily: { points: 100, data: 'level 10', date: ...., }, weekly: { points: 150, data: 'level 8', date: ...., }, overall: { points: 300, data: 'level 15', date: ...., } } We essentially store the user's top score for each scope (daily, weekly and overall). You could store a scope-per-document, which is how it initially was....but, that isn't how it's modeled and, it takes a lot more space (user and leaderboard get repeated 3x, along with the index which is on those two fields). Also, I wrote about collections vs embedded documents: http://mongly.com/Multiple-Collections-Versus-Embedded-Documents/ http://mongly.com/Multiple-Collections-Versus-Embedded-Docum... Edit: I wouldn't rely on the age of a feature request as a sign that there's something fundamentally wrong with a design. Not everything can be top priority.