5 ms·

This debate has been happening forever and really the fundamentals haven't changed. It doesn't matter if you pull data from the DB to an old middle tier or to a

This debate has been happening forever and really the fundamentals haven't changed. It doesn't matter if you pull data from the DB to an old middle tier or to a nice modern microservice architecture, you're almost always losing the performance game at that point. The database already has most of your data cached in memory, it already built statistics on the best methods to use to join the data, and the data is always local to the DB. Reading lots of a data from a DB to do the same operation in a microservice means you incur a cost of data retrieval, memory for a copy of the dataset and enough to do a join, the network speed to transfer the data over, and then you're giving up all the indexing and statistics that a database provides. There is almost never a reason for this unless you're needing to do some kind of data analysis that isn't supported by the DB. Maybe most of all this copy the data to somewhere else to do a thing is never going to scale well. Don't mind me, I'm just a retired former DB nerd.

feoren 4y ago
> the fundamentals haven't changed I believe they have, because we've gotten so much better at ORMs. ORMs get a bad rap because people use them terribly (and it's largely the ORM's fault because they encourage their own terrible use). But they are a true "change in fundamentals" that can finally end this debate. Business logic doesn't belong in the database layer, because the database layer doesn't support the level of abstraction, composability, testing, and type safety that modern programming languages afford. However, that does not mean that business logic doesn't belong in SQL. It just means you have to treat SQL as an output of your actual business layer. A good use of an ORM looks like a metaprogramming environment for conveniently building syntax trees that get converted into intelligent SQL. You know it's working well if the SQL looks somewhat like you'd write yourself and you can build one SQL statement with multiple layers that are abstracted from each other (in C#, think about passing IQueryables around). The structures are parsed into SQL and executed very explicitly only at the end of the chain, do a lot of work, and never produce SELECT N+1s. A good ORM user is thinking in SQL but writing in C# (or whatever your business layer is in). A bad use of an ORM is trying to pretend like SQL doesn't exist, or is too scary for regular programmers to think about. It has SELECT N+1s everywhere. A bad ORM user is thinking in C# and hoping the database will roughly do the correct thing.
- puffoflogic 4y ago
  > A good ORM user is thinking in SQL but writing in C# (or whatever your business layer is in). That doesn't sound like metaprogramming; it sounds like insanity brought about by bureaucratic limitations on language choice.
  - fifilura 4y ago
    To be fair, there is one important thing the ORM brings though. Sanatizing inputs.
    - zanecodes 4y ago
      Don't sanitize your inputs; parameterize your queries instead.
      - Tostino 4y ago
        I see those as two different solutions to two different, but slightly overlapping problems.
        pessimizer 4y ago
        Going to keep those problems a secret?
        Lvl999Noob 4y ago
        Imo, the problems are the same but the conditions are different. If the query is used many times, parameterize it. If the input is used many times, sanitize it. If both are used many times, parameterize.
      - robocat 4y ago
        Parameterising works for individual fields in a statement. However for complex queries (the reason for the meta-programmimg comment) you can’t always parameterise the additional subqueries/tables/fields. You can use stored procedures, but that just shifts the necessary code from one language to SQL, and the SQL doesn’t have a robust library you can just use.
deleted 4y ago
[deleted]

feoren 4y ago

> the fundamentals haven't changed I believe they have, because we've gotten so much better at ORMs. ORMs get a bad rap because people use them terribly (and it's largely the ORM's fault because they encourage their own terrible use). But they are a true "change in fundamentals" that can finally end this debate. Business logic doesn't belong in the database layer, because the database layer doesn't support the level of abstraction, composability, testing, and type safety that modern programming languages afford. However, that does not mean that business logic doesn't belong in SQL. It just means you have to treat SQL as an output of your actual business layer. A good use of an ORM looks like a metaprogramming environment for conveniently building syntax trees that get converted into intelligent SQL. You know it's working well if the SQL looks somewhat like you'd write yourself and you can build one SQL statement with multiple layers that are abstracted from each other (in C#, think about passing IQueryables around). The structures are parsed into SQL and executed very explicitly only at the end of the chain, do a lot of work, and never produce SELECT N+1s. A good ORM user is thinking in SQL but writing in C# (or whatever your business layer is in). A bad use of an ORM is trying to pretend like SQL doesn't exist, or is too scary for regular programmers to think about. It has SELECT N+1s everywhere. A bad ORM user is thinking in C# and hoping the database will roughly do the correct thing.

puffoflogic 4y ago
> A good ORM user is thinking in SQL but writing in C# (or whatever your business layer is in). That doesn't sound like metaprogramming; it sounds like insanity brought about by bureaucratic limitations on language choice.
- fifilura 4y ago
  To be fair, there is one important thing the ORM brings though. Sanatizing inputs.
  - zanecodes 4y ago
    Don't sanitize your inputs; parameterize your queries instead.
    - Tostino 4y ago
      I see those as two different solutions to two different, but slightly overlapping problems.
      - pessimizer 4y ago
        Going to keep those problems a secret?
      - Lvl999Noob 4y ago
        Imo, the problems are the same but the conditions are different. If the query is used many times, parameterize it. If the input is used many times, sanitize it. If both are used many times, parameterize.
    - robocat 4y ago
      Parameterising works for individual fields in a statement. However for complex queries (the reason for the meta-programmimg comment) you can’t always parameterise the additional subqueries/tables/fields. You can use stored procedures, but that just shifts the necessary code from one language to SQL, and the SQL doesn’t have a robust library you can just use.

deleted 4y ago

[deleted]