4 ms·

Funny, I've been using MongoDB for well over a year, and I use it not for scalability/durability, but because it's so nice to develop on top of. Simply put: it

• michaelchisari 16y ago
  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.
• mhd 16y ago
  Most of the time, I get the reverse problem: It's pretty odd to map data to objects. For a lot of applications, a relational view is pretty natural. That's why I never got the "NoSQL instead of RDBMS" rhetoric. A document-oriented database is just another tool in your kit. Choose the right one, depending on the usual format of the data. If one is always reaching for one tool, it's much more likely that there's not enough expertise with other tools than that this one tool is so great and universally applicable. Silver bullets…