3 ms·

You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm. When I am using a high level

by gernak 7y ago

You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm. When I am using a high level programming language, it is merely helping me do things like manage memory. I am not constantly wishing I could drop down and work with pointers and so on. It is a foundational paradigm that builds on the top of the one before it. ORMs just present a different, incompatible paradigm.

shkkmo 7y ago
> You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm How does an ORM prevent you from using any SQL features? When you do the sorts of complicated things that are out of scope for an ORM, you do them in SQL. I don't see any incompatibility.
scarface74 7y ago
There are plenty of scenarios in certain verticals where you need to control memory management like games and others where you need to program in assembly. Garbage collection is an incompatible paradigm where you need to control when memory is allocated and freed. Back in the day when I was doing C, there were times when we just couldn’t get the speed we needed from the compiler. I wrote inline assembly. Does that mean C was unsuitable because it was incompatible with our performance requirements?
- gernak_ 7y ago
  An ORM is not a high-level version of SQL though. A more accurate metaphor for an ORM would be like a converter from one high level programming language that is object oriented, to another high level programming language that is functional.
  - scarface74 7y ago
    In the case of C#, LINQ is a declarative built in part of the language. At runtime, it is converted into an AST and if you use Entity Framework, it is translated into SQL - another declarative language. You can theoretically express any standard SQL query in LINQ even though outer joins can be obtuse at first. The translation may not be as optimal as hand written sql, but no compiler can translate code into assembly that would be as optimized as someone who could hand roll their own. We decided decades ago that high level languages were worth the trade off most of the time.
gnaritas 7y ago
> You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm. Not remotely true. ORM's are great at mapping views/procs, and you can use any feature of the db you want in a view or proc. Using an ORM does not mean not being able to your database to its fullest extent.

by gernak 7y ago

shkkmo 7y ago

> You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm How does an ORM prevent you from using any SQL features? When you do the sorts of complicated things that are out of scope for an ORM, you do them in SQL. I don't see any incompatibility.

scarface74 7y ago

There are plenty of scenarios in certain verticals where you need to control memory management like games and others where you need to program in assembly. Garbage collection is an incompatible paradigm where you need to control when memory is allocated and freed. Back in the day when I was doing C, there were times when we just couldn’t get the speed we needed from the compiler. I wrote inline assembly. Does that mean C was unsuitable because it was incompatible with our performance requirements?

gernak_ 7y ago
An ORM is not a high-level version of SQL though. A more accurate metaphor for an ORM would be like a converter from one high level programming language that is object oriented, to another high level programming language that is functional.
- scarface74 7y ago
  In the case of C#, LINQ is a declarative built in part of the language. At runtime, it is converted into an AST and if you use Entity Framework, it is translated into SQL - another declarative language. You can theoretically express any standard SQL query in LINQ even though outer joins can be obtuse at first. The translation may not be as optimal as hand written sql, but no compiler can translate code into assembly that would be as optimized as someone who could hand roll their own. We decided decades ago that high level languages were worth the trade off most of the time.

gnaritas 7y ago

> You can only use a fraction of the features of a SQL database when you use an ORM because they don't translate to the new paradigm. Not remotely true. ORM's are great at mapping views/procs, and you can use any feature of the db you want in a view or proc. Using an ORM does not mean not being able to your database to its fullest extent.