3 ms·

What is wrong with writing a raw SQL for such a simple thing? I never want to fight with a tool for achieving such a simple query. Tools are supposed to help an

by h1d 8y ago

What is wrong with writing a raw SQL for such a simple thing? I never want to fight with a tool for achieving such a simple query. Tools are supposed to help and when queries tend to get complicated, I think that's when ORM starts to fail with performance. So, I don't find a room for it. I'd rather learn how SQL works instead of how to get random ORM of the time to work like it should.

nulagrithom 8y ago
> What is wrong with writing a raw SQL for such a simple thing? Mostly query composition. I run in to this a lot. Say I need to write a less-than-simple query and reuse it with several different WHERE clauses. Sometimes I think I just want migrations, not so much an ORM. I want to define views and stored procs in my repo and have them move to prod automatically, but I still want to write in straight SQL.
- sanderjd 8y ago
  This resonates with me. But the other super critical thing (which was the first part of my original comment, and which nobody has really highlighted here) is a mature query construction library that knows how to properly protect against injection.
  - ris 8y ago
    In all fairness a properly used sql connector library will hopefully do this too.
- ntqz 8y ago
  Although the majority of what I do is in Python, I've taken to using Flyway for DB migrations. A lot of what I do is using some of the more esoteric features of PG (think domains, custom aggregate functions, etc), so the ability to run migrations as direct SQL is great.
msbarnett 8y ago
If you're not doing anything to manage and autogen your queries, does that imply that any change to the model's table entails manually updating all N different queries that touch the table in your application? I'd be really concerned about the fragility of having that many disparate sources of truth about the structure of your data. Particularly when errors are only going to be discovered when the query actually runs. You don't need to have an ORM, but at the same time, having no abstraction above "hardcode every query" is its own enormous set of problems.
sanderjd 8y ago
Don't get me wrong: everyone should learn SQL and learn it well. But a query construction and composition abstraction is also an invaluable tool. Fortunately, it is quite achievable to learn both things well.

by h1d 8y ago

nulagrithom 8y ago

> What is wrong with writing a raw SQL for such a simple thing? Mostly query composition. I run in to this a lot. Say I need to write a less-than-simple query and reuse it with several different WHERE clauses. Sometimes I think I just want migrations, not so much an ORM. I want to define views and stored procs in my repo and have them move to prod automatically, but I still want to write in straight SQL.

sanderjd 8y ago
This resonates with me. But the other super critical thing (which was the first part of my original comment, and which nobody has really highlighted here) is a mature query construction library that knows how to properly protect against injection.
- ris 8y ago
  In all fairness a properly used sql connector library will hopefully do this too.
ntqz 8y ago
Although the majority of what I do is in Python, I've taken to using Flyway for DB migrations. A lot of what I do is using some of the more esoteric features of PG (think domains, custom aggregate functions, etc), so the ability to run migrations as direct SQL is great.

msbarnett 8y ago

If you're not doing anything to manage and autogen your queries, does that imply that any change to the model's table entails manually updating all N different queries that touch the table in your application? I'd be really concerned about the fragility of having that many disparate sources of truth about the structure of your data. Particularly when errors are only going to be discovered when the query actually runs. You don't need to have an ORM, but at the same time, having no abstraction above "hardcode every query" is its own enormous set of problems.

sanderjd 8y ago

Don't get me wrong: everyone should learn SQL and learn it well. But a query construction and composition abstraction is also an invaluable tool. Fortunately, it is quite achievable to learn both things well.