4 ms·

There are many reasons why ORMs work better than it did earlier. For one, people prefer simpler database schema these days - and what used to be larger monolith

by jeswin 6y ago

There are many reasons why ORMs work better than it did earlier. For one, people prefer simpler database schema these days - and what used to be larger monolithic apps are often broken into micro services. Earlier, you'd have one big database - today you'll have many. And ORMs are great with simple queries and joins. The language plays a big role in whether an ORM is actually useful or not. In the .Net world, ORMs work quite well because querying capabilities are integrated into the language. Queries and schema are verified at compile-time, and I wouldn't trade it for slightly better performance or control. On the other hand, with Python (or say Node), or with Java and Hibernate the wins are smaller. Of course, there will be some queries which are just better written in plain SQL. If you're willing to accept that, ORMs are a good tool in your toolbox.

dnautics 6y ago
If you're talking about linq I wouldn't call that an orm.
- tehlike 6y ago
  Linq + ef or linq + nhibernate. You can use linq to query against both.
  - dnautics 6y ago
    Linq is more of a query builder than an orm, or am I wrong?
  - tehlike 6y ago
    Ef, entity framework, exposes an iqueryable which you can use linq to query against. Meaning you can use your orms entity model and query your database In a type-safe compile-time-checked manner.
- jeswin 6y ago
  Linq is not an ORM, but Entity Framework is. But what makes EF interesting is Linq.
isbvhodnvemrwvn 6y ago
You can get some benefits you mention by using query builders (like jOOQ). They can get unwieldy at times (not part of the language), but you can drop directly to SQL if you need to, and they tend to be simpler than ORMs in various use cases.
- cies 6y ago
  Saw the title, searched the comments for jOOQ. jOOQ needs to be mentioned in this context. With jOOQ you basically write Java-SQL-DSL, and with some code generation from your schema you have really neat type safety (and code completion). String SQL queries are not the answer to ORMs, imho, we need a level in between. jOOQ provides a really cool set of features in that space.
- arusahni 6y ago
  Wasn't familiar with jOOQ - neat! Looks like it covers the same set of use-cases that SQLAlchemy-core handles in Python.
Cthulhu_ 6y ago
Counterpoint: By migrating to microservices, you're moving the problem, not solving it. Sure, your individual services and tables are simpler, but when you need to combine the data, update it, etc you run into big issues that aren't trivial to solve.

by jeswin 6y ago

dnautics 6y ago

If you're talking about linq I wouldn't call that an orm.

tehlike 6y ago
Linq + ef or linq + nhibernate. You can use linq to query against both.
- dnautics 6y ago
  Linq is more of a query builder than an orm, or am I wrong?
- tehlike 6y ago
  Ef, entity framework, exposes an iqueryable which you can use linq to query against. Meaning you can use your orms entity model and query your database In a type-safe compile-time-checked manner.
jeswin 6y ago
Linq is not an ORM, but Entity Framework is. But what makes EF interesting is Linq.

isbvhodnvemrwvn 6y ago

You can get some benefits you mention by using query builders (like jOOQ). They can get unwieldy at times (not part of the language), but you can drop directly to SQL if you need to, and they tend to be simpler than ORMs in various use cases.

cies 6y ago
Saw the title, searched the comments for jOOQ. jOOQ needs to be mentioned in this context. With jOOQ you basically write Java-SQL-DSL, and with some code generation from your schema you have really neat type safety (and code completion). String SQL queries are not the answer to ORMs, imho, we need a level in between. jOOQ provides a really cool set of features in that space.
arusahni 6y ago
Wasn't familiar with jOOQ - neat! Looks like it covers the same set of use-cases that SQLAlchemy-core handles in Python.

Cthulhu_ 6y ago

Counterpoint: By migrating to microservices, you're moving the problem, not solving it. Sure, your individual services and tables are simpler, but when you need to combine the data, update it, etc you run into big issues that aren't trivial to solve.