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.

  • Cyclohexane@lemmy.ml
    ·
    10 months ago

    I find SQL to be easy enough to write without needing generation. It is very well documented, and it is very declarative and English-like. More than any ORM, imo.

    • Lmaydev@programming.dev
      ·
      10 months ago

      I don't c#'s EF is brilliant

      dbContext.Products.Where(p => p.Price < 50).GroupBy(p => p.Category.Id).ToArray()
      • JWBananas@startrek.website
        ·
        10 months ago
          p.*
FROM
  Products p
WHERE
  p.Price < 50
GROUP BY
  p.Category_Id```

Meanwhile the ORM is probably generating something stupid and unnecessarily slow like this:

```SELECT
  p.*, c.*
FROM
  Products p
JOIN
  Category c
  USING (Category_Id)
WHERE
  p.Price < 50
GROUP BY
  c.Category_Id```

Now stop using goddamn capital letters in your table and field names. And get off my lawn!