That's not a very convincing example.

Let's ignore the fact that it's a trivially small example to begin with. I don't think it's very representative of larger apps, especially ones that are far more complex than a very simplistic blog system.

And let's ignore the fact that the SQL-based one is around 10% shorter than the MongoDB one, too, in terms of their line counts.

The SQL-based one makes the queries very clearly visible. It's easier to find the queries, and for anyone who knows SQL it's very clear at a quick glance what they're doing. It's much harder to isolate the queries in the MongoDB one. The visibility of the SQL queries makes maintenance easier, and performance tuning easier.

And I don't buy the dynamic query argument. Those are often the most fragile ones used, and should generally be avoided, if possible. It's better to have two or more similar queries than it is one that's built dynamically. Even then, it's often possible to write a single query with more complex filtering that can handle numerous very different cases.

At best, the MongoDB example is roughly equivalent to the SQL one. In practice, you're trading off a huge number of benefits of relational databases (SQL usually being one of them) for little to no gain when opting for MongoDB instead.

Thanks for checking out the example and I agree that it may be overly trivial. We do plan to investigate this further and will blog about it at https://starthq.com/blog/

I really think that depending on one's requirements it should be possible to query relational database using MongoDB syntax and use (basic) relational queries on Mongo data.

There have been tools like Metrica (https://starthq.com/apps/metrica) that do this, but we're working on implementing that as a Node package.

It's probably nice if you only write JS (say, you write a node.js app). To me SQL is still the best query language we have. It's usable amongst a wide range of database servers, from tiny embedded sqlite to oracle. It's _easy_.

One side that NoSQL fails on is to not have a common query language, imo. You chose MongoDB in your project and want to migrate to another database? Not that easy. Switch from MySQL to Postgres? Probably not a drop-in replacement, but much easier to do.

> To me SQL is still the best query language we have.

OQL! Okay, so nobody ever implemented OQL. But there are OQL-inspired query languages in production which i prefer to SQL for routine use, such as JPQL.

One reason for that preference is the ability to join through foreign keys with a syntax which resembles property access on objects:

  select e
  from Employee e
  where e.department.head.manager.level = 'VP'

This beats the equivalent SQL:

  select e.*
  from Employee e
  join Department d using (department_id)
  join Employee h on d.head_id = h.employee_id
  join Employee m on h.manager_id = m.employee_id
  where m.level = 'VP'

Admittedly, whilst JQPL is nice for this sort of routine fetch-and-filter stuff, it lacks the more powerful features of SQL like window functions, recursive common table expressions, etc. I don't often need those, but when i do, it would be rather painful to do without them.

>To me SQL is still the best query language we have

I agree 100% there. I think orient db proves that it is possible to use sql in a no sql database. Though I think not all databases are designed to support entire sql querying mechanism.

Your comparison is not apt; an ORM can be used for any SQL flavor.

Having written an ORM myself back in 2000 and used Hibernate and JPA for many years, I'm now of the opinion that ORMs are an unnecessary, leaky abstraction in the modern day of dynamic languages.

One is better off talking directly to the data store and effectively streaming data out via a REST API.

Why would someone downvote this?

ORMs certainly are a leaky abstraction, and they certainly do come with a penalty in performance and expressiveness. Is it really downvote-worthy to add the opinion that they are unnecessary?

There are SQL libraries out there that make writing raw SQL unnecessary and also provide you with all the semantics of actual SQL, with no performance or expressiveness overhead. SQLAlchemy for Python is an example, there are others.

Yes, at one startup I worked on we had written one of those as well (https://github.com/akshell/docs/blob/master/guide/db.rst).

The problem is they are still an abstraction. You write these queries using chaining or whatever but when something goes wrong you still need to look at the generated SQL statements.

With MongoDB, the query you write in your app is exactly the same as the query you run from the MongoDB shell and I like that. I can prototype the query in the shell and then copy paste it into the application code. When the application code is producing unexpected results, I can easily debug it in the shell.

You're comparing concatenating strings vs building data structures. Naturally the latter is preferable. It's fairly trivial to represent SQL as data structures in your host language (an embedded DSL if you like) and then you have the benefits of compositionality you currently have with JSON.

That's why there are nice libraries for building SQL ASTs and generating code for various databases, like SQLAlchemy. They also benefit from not being ambiguous and arbitrarily constrained (like Mongo's joke query language).