Hacker News Reader

Comment by lima | Hacker News Reader

> SQL is a great language for ad-hoc exploration of data or for building aggregates over data sets. It’s an absolutely miserable language for programmatically accessing data.

Disagreed. SQL is great for programmatically accessing data, especially with a good client library like SQLAlchemy. I have a much easier time understanding and, most importantly, debugging SQL than MongoDB's query language.

It did not solve the injection issue either, MongoDB injections are a thing[1] and they're much harder to reason about than SQL injections.

[1]: https://www.owasp.org/index.php/Testing_for_NoSQL_injection

View on HN

I agree with your disagreement. In fact the writer seems to have it backwards.

The hard part of SQL is learning complex queries for "ad hoc exploration of data or for building aggregates over data sets": joins, unions, window functions, recursive common table expressions, etc. (Nevertheless it's still shorter than doing the same thing in some procedural language.)

The easy part is "programmatically accessing data." What is meant by "programmatically accessing data" anyway, besides "select * from . . ."? The writer's main criticism is:

  > If you want to insert data,
  > you’ll probably end up constructing the string (?,?,?,?,?,?,?,?)
  > and counting arguments very carefully.

With PHP's built-in PDO library, you can use named placeholders instead of question marks:

  select *
  from fruits
  where color = :color and calories < :calories

No question-mark counting required.

I believe the authors point is that you have to use SQLAlchemy for that experience. Natively, the experience is much harder and that's why ORMs (like SQLALchemy) have been built. In MongoDB, the driver matches the command line interface 1-1, there is no need for a higher level wrapper so that you can use your database.

That's actually a myth. One thing is Object Mapping, which is repetitive, but whenever there is a layer of indirection to "hide SQL from the developer", then there will be developer pain and waste of developer time.

SQL is just a language and needs to be learned. It's not hard and being declarative it also teaches to think differently than imperative programming.

Want to query in Javascript? Sure go ahead, but don't say SQL is harder.

> SQL is just a language and needs to be learned

Assembler is just a language and needs to be learned.

Oh wait. Nothing needs to be learned and there are always cases for higher up abstractions. Especially SQL which can get extremely complex if it needs to.

Do you compare assembler with SQL?

I think a good ORM is one that isn#t just "hide SQL from the devs" and rather "hide trivial SQL from the devs and let them get dirty if they want to".

Some ORMs I've worked with allowed me to completely bypass the ORM system while still getting most of the benefits. I do recall a ORM that I've use a long while ago that didn't support reading Views as objects but it could be trivially added simply by writing a custom query method which was unpacked like any other query into the object and that worked for Views then.

And then you have to maintain your own consistency layer in the application because you'll either duplicate data or use relations in Mongo like you would in a relational database.

I've found there are few ORMs like SQLAlchemy. Most common ORMs hide the SQL, which is what you were talking about. With SQLAlchemy the SQL seeps out into the code, like SQL blending in with Python.

Reply on news.ycombinator.com