4 ms·

Agreed - my experience with non-SQL tech (ORMs) with Django and ASP.net MVC made me really appreciate SQL so much. Most of the time I felt everything would be s

Agreed - my experience with non-SQL tech (ORMs) with Django and ASP.net MVC made me really appreciate SQL so much. Most of the time I felt everything would be so much easier using raw SQL instead of dealing with model objects. It also felt like in their quest to replace SQL and make things "simpler" they were recreating some db features again.

SoftTalker 4y ago
Yep. That's why I write most of my logic in stored procedures. Working with tables and queries is so much easier in PL/pgsql than dealing with ORMs and their leaky abstractions. My application code just calls stored procedures. It's unaware of the tables and underlying data model.
- sivers 4y ago
  Cool! I do this, but I haven't seen anyone else do it. Is any of your code public? I wrote about it at https://sive.rs/pg https://sive.rs/pg and posted my SQL shopping cart at https://github.com/sivers/store https://github.com/sivers/store Please contact me if you'd like to share tips: https://sive.rs/contact https://sive.rs/contact
  - SoftTalker 4y ago
    No I don't really have any public code. I read your blog post and I agree 100% The database is the easiest place to code business logic that pertains to the data. Write it once, it's available for all client applications.
- 3pm 4y ago
  There is no one-size-fits-all, but most of the time I would be against SP because: 1) SPs usually mix persistence concerns with business logic. Making it harder to understand business intent. I find objects much more expressive than raw data. Sometimes you want to concentrate on the plain logic, without worrying about how something gets saved. Also you will not have to rewrite everything if you ever want to change how something is stored. Sometimes people switch from mysql to pg, or even doc or kv database. Keeping business logic separate enables this. And good ORM enables this separation. 2) Refactoring tooling and unit tests. SPs are lacking here significantly compared to general purpose languages. 3) Business logic outside of DB allows easier horizontal scaling.
  - SoftTalker 4y ago
    In my experience, the application framework changes much more often than the database. PHP, ASP, ASP.NET, Angular, React, Django, whatever. Pick a year, pick a framework. The database stays steady.
    - 3pm 4y ago
      I agree. But I found that approaching it _as_if_ database will change makes for a more focused model. Same goes for UI frameworks. Basically thriving toward Hexagonal architecture, without being too dogmatic.
3pm 4y ago
It can depend on your perspective. If you look at an app and just see tables and data then yes, model objects stand in a way. If you describe your app as this thing that manipulates the database then I can see how a layer of abstraction can be annoying. But people write 'billing apps' not 'data manipulator apps', so there is this pesky business logic. ORM helps you separate business logic from data access logic. If you don't need this separation then it just stands in the way. ORM is not perfect, but most abstractions leak to some extent. I think it also depends on how the 'model objects' are implemented. Is it Active Record or Domain Model? I think most of the complaints about ORM are actually complaints about Active Record / DAO, or just a crappy implementation. Also nothing wrong with using SQL in an otherwise ORMed application. Just harder to unit test, refactor etc.

SoftTalker 4y ago

Yep. That's why I write most of my logic in stored procedures. Working with tables and queries is so much easier in PL/pgsql than dealing with ORMs and their leaky abstractions. My application code just calls stored procedures. It's unaware of the tables and underlying data model.

sivers 4y ago
Cool! I do this, but I haven't seen anyone else do it. Is any of your code public? I wrote about it at https://sive.rs/pg https://sive.rs/pg and posted my SQL shopping cart at https://github.com/sivers/store https://github.com/sivers/store Please contact me if you'd like to share tips: https://sive.rs/contact https://sive.rs/contact
- SoftTalker 4y ago
  No I don't really have any public code. I read your blog post and I agree 100% The database is the easiest place to code business logic that pertains to the data. Write it once, it's available for all client applications.
3pm 4y ago
There is no one-size-fits-all, but most of the time I would be against SP because: 1) SPs usually mix persistence concerns with business logic. Making it harder to understand business intent. I find objects much more expressive than raw data. Sometimes you want to concentrate on the plain logic, without worrying about how something gets saved. Also you will not have to rewrite everything if you ever want to change how something is stored. Sometimes people switch from mysql to pg, or even doc or kv database. Keeping business logic separate enables this. And good ORM enables this separation. 2) Refactoring tooling and unit tests. SPs are lacking here significantly compared to general purpose languages. 3) Business logic outside of DB allows easier horizontal scaling.
- SoftTalker 4y ago
  In my experience, the application framework changes much more often than the database. PHP, ASP, ASP.NET, Angular, React, Django, whatever. Pick a year, pick a framework. The database stays steady.
  - 3pm 4y ago
    I agree. But I found that approaching it _as_if_ database will change makes for a more focused model. Same goes for UI frameworks. Basically thriving toward Hexagonal architecture, without being too dogmatic.

3pm 4y ago

It can depend on your perspective. If you look at an app and just see tables and data then yes, model objects stand in a way. If you describe your app as this thing that manipulates the database then I can see how a layer of abstraction can be annoying. But people write 'billing apps' not 'data manipulator apps', so there is this pesky business logic. ORM helps you separate business logic from data access logic. If you don't need this separation then it just stands in the way. ORM is not perfect, but most abstractions leak to some extent. I think it also depends on how the 'model objects' are implemented. Is it Active Record or Domain Model? I think most of the complaints about ORM are actually complaints about Active Record / DAO, or just a crappy implementation. Also nothing wrong with using SQL in an otherwise ORMed application. Just harder to unit test, refactor etc.