Some backend libraries let you write SQL queries as they are and deliver them to the database. They still handle making the connection, pooling, etc.

ORMs introduce a different API for making SQL queries, with the aim to make it easier. But I find them always subpar to SQL, and often times they miss advanced features (and sometimes not even those advanced).

It also means every time I use a ORM, I have to learn this ORM’s API.

SQL is already a high level language abstracting inner workings of the database. So I find the promise of ease of use not to beat SQL. And I don’t like abstracting an already high level abstraction.

Alright, I admit, there are a few advantages:

  • if I don’t know SQL and don’t plan on learning it, it is easier to learn a ORM
  • if I want better out of the box syntax highlighting (as SQL queries may be interpreted as pure strings)
  • if I want to use structures similar to my programming language (classes, functions, etc).

But ultimately I find these benefits far outweighed by the benefits of pure sql.

  • Von_Broheim@programming.devEnglish
    11·
    1 year ago

    Yeah, that’s great, until you need to conditionally compose a query. Suddenly your pre baked queries are not enough. So you either:

    • create your own shitty ORM based on string concatenation
    • create your own shitty ORM
    • or use a well supported ORM, those almost always support query composition and native queries

    You write like it’s ORM vs native. ORMs let you write native queries and execute them while also doing all the tedious work for you such as:

    • mapping results to model objects
    • SQL injection safety
    • query composition
    • connection builders
    • transaction management

    So if you love native queries write native queries in an ORM which will do all the tedious shit for you.