4 ms·

It's a joy to use. We work with objects in our languages. We don't work with rows of data. And I totally get that, I really do, but to me, that's more of an is

It's a joy to use. We work with objects in our languages. We don't work with rows of data. And I totally get that, I really do, but to me, that's more of an issue of personal preference, and less of an issue of a clear advantage. There's nothing wrong with personal preferences. For instance, I like schemas that aren't easily changed, and a clear separation of logic and data, and I prefer to think of data as rows, not objects. But that's my personal preference. I'm more interested in how the functional approach to a use case would make NoSQL the clearly superior technology in that scenario.

sazzal 16y ago
You can still think of data as 'rows' with MongoDB - objects belong to a collection, which is analogous to a table - and you can query and select only specific fields. The advantage is that you aren't nearly as restricted in the kinds of data you can build. SQL often forces you to split logically related data across several tables and wrestle with complicated joins, simply because a row can't contain sub-arrays or hashes. Of course, there's no silver bullet - some times you DO want to group together logically different data in a same query. But I've found that in general, I'm not fighting the DB as much when building stuff using MongoDB.
- lneves 16y ago
  <quote>simply because a row can't contain sub-arrays or hashes</quote> This is not true at all. At least in PostgreSQL you can have arrays and hashes: http://www.postgresql.org/docs/current/static/arrays.html http://www.postgresql.org/docs/current/static/arrays.html http://www.postgresql.org/docs/current/static/hstore.html http://www.postgresql.org/docs/current/static/hstore.html
  - w1nk 16y ago
    Have you actually looked at or used the array stuff in postgres? It's pretty horrible syntactically and worse, very explicit in it's recommended use. "Tip: Arrays are not sets; searching for specific array elements can be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale better for a large number of elements." Searching an array is a pretty common task, Mongo does really well in its ability to search into objects in a document. I had to laugh a little at one of the sample queries: SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2 FROM (SELECT '[1:1][-2:-1][3:5]={{{1,2,3},{4,5,6}}}'::int[] AS f1) AS ss; Seriously?
    - lneves 16y ago
      Yes I've looked at them. I use them every day. The example you posted its difficult to parse because it deals with multidimensional arrays and also populating one in the inner query. The simple, and much more common case of one dimension arrays is very straightforward. Can you show me the equivalent in MongoDB? About the performance/scalability warning; I don't deal with very large arrays, a couple hundred items max, and when using a GIN index over the array field, search queries are screamingly fast.
      - w1nk 16y ago
        Sure, check out: http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching+into+Objects%29 http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching...
        lneves 16y ago
        I do not think that this is equivalent, it looks like querying complex JSON objects and not "simple" arrays. From the "Array Element by Position" example: db.blogposts.find( { "comments.0.by" : "Abe" } ) PostgreSQL doesn't have JSON support but it does have XML/Xpath support. If you stored XML documents in PostgreSQL the similar query to the MongoDB one would be something like this: select * from blogposts where (xpath('/comments[0]/@by', doc))::text[] = array['Abe'] Yes it's a little more verbose but not terrible so... at least in my opinion.
nphase 16y ago
There is absolutely a clear advantage when it comes to prototyping and rapid development. Specific example: Ever built a crawler that harvested hundreds of gigabytes of raw data and then realized you needed to make a schema change later? I don't want to take the time to think about every single use case and every single column I'll need and their datatypes. I just want to move on so that I can start doing things with the data. I still think of data as rows in MongoDB, but the lack of a fixed schema makes life seriously easy. That means my schema is defined in the application (and only the application) and is subject to versioning. Want an extra column? Just add it to your application and you're done. No need to promote a slave and cycle through while waiting hours upon hours for each table to build.

sazzal 16y ago

You can still think of data as 'rows' with MongoDB - objects belong to a collection, which is analogous to a table - and you can query and select only specific fields. The advantage is that you aren't nearly as restricted in the kinds of data you can build. SQL often forces you to split logically related data across several tables and wrestle with complicated joins, simply because a row can't contain sub-arrays or hashes. Of course, there's no silver bullet - some times you DO want to group together logically different data in a same query. But I've found that in general, I'm not fighting the DB as much when building stuff using MongoDB.

lneves 16y ago
<quote>simply because a row can't contain sub-arrays or hashes</quote> This is not true at all. At least in PostgreSQL you can have arrays and hashes: http://www.postgresql.org/docs/current/static/arrays.html http://www.postgresql.org/docs/current/static/arrays.html http://www.postgresql.org/docs/current/static/hstore.html http://www.postgresql.org/docs/current/static/hstore.html
- w1nk 16y ago
  Have you actually looked at or used the array stuff in postgres? It's pretty horrible syntactically and worse, very explicit in it's recommended use. "Tip: Arrays are not sets; searching for specific array elements can be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale better for a large number of elements." Searching an array is a pretty common task, Mongo does really well in its ability to search into objects in a document. I had to laugh a little at one of the sample queries: SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2 FROM (SELECT '[1:1][-2:-1][3:5]={{{1,2,3},{4,5,6}}}'::int[] AS f1) AS ss; Seriously?
  - lneves 16y ago
    Yes I've looked at them. I use them every day. The example you posted its difficult to parse because it deals with multidimensional arrays and also populating one in the inner query. The simple, and much more common case of one dimension arrays is very straightforward. Can you show me the equivalent in MongoDB? About the performance/scalability warning; I don't deal with very large arrays, a couple hundred items max, and when using a GIN index over the array field, search queries are screamingly fast.
    - w1nk 16y ago
      Sure, check out: http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching+into+Objects%29 http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching...
      - lneves 16y ago
        I do not think that this is equivalent, it looks like querying complex JSON objects and not "simple" arrays. From the "Array Element by Position" example: db.blogposts.find( { "comments.0.by" : "Abe" } ) PostgreSQL doesn't have JSON support but it does have XML/Xpath support. If you stored XML documents in PostgreSQL the similar query to the MongoDB one would be something like this: select * from blogposts where (xpath('/comments[0]/@by', doc))::text[] = array['Abe'] Yes it's a little more verbose but not terrible so... at least in my opinion.

nphase 16y ago

There is absolutely a clear advantage when it comes to prototyping and rapid development. Specific example: Ever built a crawler that harvested hundreds of gigabytes of raw data and then realized you needed to make a schema change later? I don't want to take the time to think about every single use case and every single column I'll need and their datatypes. I just want to move on so that I can start doing things with the data. I still think of data as rows in MongoDB, but the lack of a fixed schema makes life seriously easy. That means my schema is defined in the application (and only the application) and is subject to versioning. Want an extra column? Just add it to your application and you're done. No need to promote a slave and cycle through while waiting hours upon hours for each table to build.