Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What ORMs have taught me: just learn SQL (2014)

woz.posthaven.com

Post reply on HN
Print view View original

331–340 of 360 posts

Re: What ORMs have taught me: just learn SQL (2014)

#331

Post by manigandham »

bunderbunder wrote: post #289
manigandham wrote: post #252

One of the most endless and pointless debates. 99% of the time, an ORM is fantastic and will make you more productive while providing performance, security, and maintainability. They come in many sizes from thin wrappers around a db connection to full-featured frameworks. For the other 1%, use raw SQL, or perhaps a query building tool to help with parameterization, composability, etc. In fact, modern ORMs will even l…

All of these endless debates seem to boil down to two different groups who work in two different problem domains talking past each other. I've personally never seen an ORM lead to success in the long run. But I also work in a space where queries frequently end up involving something that ORMs typically don't handle well: merge statements and pivot statements, window functions, management of the lock escalation policy…

Yes, you are talking the 1% of use-cases, which is probably more like 10% these days with more complex software. Most business apps are just CRUD, but if you're doing analytics queries and such with tabular/pivot/nested result sets, then an ORM isn't going to do much for you.

SQL is the database interface so of course using it directly without abstraction helps you get all the power and control. I have seem some cases though where a query-builder with a solid DSL can be a good middle-ground.

Re: What ORMs have taught me: just learn SQL (2014)

#332

Post by [deleted] »

manigandham wrote: post #331
bunderbunder wrote: post #289

Earlier quoted context omitted.

All of these endless debates seem to boil down to two different groups who work in two different problem domains talking past each other. I've personally never seen an ORM lead to success in the long run. But I also work in a space where queries frequently end up involving something that ORMs typically don't handle well: merge statements and pivot statements, window functions, management of the lock escalation policy…

Yes, you are talking the 1% of use-cases, which is probably more like 10% these days with more complex software. Most business apps are just CRUD, but if you're doing analytics queries and such with tabular/pivot/nested result sets, then an ORM isn't going to do much for you. SQL is the database interface so of course using it directly without abstraction helps you get all the power and control. I have seem some case…

[deleted]

Re: What ORMs have taught me: just learn SQL (2014)

#333

Post by scarface74 »

zkomp wrote: post #299
zkomp wrote: post #284

Earlier quoted context omitted.

I like data. A database is created to handle it, give you tools to query, modify, scale, secure the data. A rest api... how and why should it be responsible for your data? It solved a different problem. You might not even need a database I guess, and then anything goes. I need and like my database, and have suffered trying to get along with different ORMs. SQL is so good at what it is designed to do if you just let i…

(have we come to some max nesting level here, cant reply to the child comment) One db can be a problem, or a strenght depending on the domain; And I really dislike religious design, esp microservices. I have less problems by avoiding ORMs (and religios microservice arch, or fundamentalist interpretations of rest) Database handles the shared state in a heterogenous environment. We need it to be centralized to keep tra…

Database handles the shared state in a heterogenous environment. We need it to be centralized to keep track of money, the apps can't do that, two independent databases cant do that either.

Why can't apps "keep track of money"? I'm assuming you're referring to transactions. Apps can create transactions and you can share transactions across apps using distributed transaction (I'm not saying distributed transaction is a good idea).

Re: What ORMs have taught me: just learn SQL (2014)

#334

Post by scarface74 »

walshemj wrote: post #326
scarface74 wrote: post #237

Earlier quoted context omitted.

Usually with most modern automated deployments, you keep your build artifacts in a package (zip file, tar, etc.) and run a script to deploy it to your target system. Rolling back is a simple matter of installing the previous archive. That doesn't just apply to code anymore. You can treat "infrastructure as code" also. You can do A/B upgrades, rollbacks, etc. There is so much better tooling around regular code than sq…

Sounds like you have been working at companies with poor procedures and employees without the required skills. Avoiding SQL in favour of an ORM or inline sql is 95% of the time a sign of laziness.

You did see me preach about all of the capabilities for unit testing without a database dependency, type safety, flexibility (with Linq I can switch back and forth between an RDMS and NoSql without any code changes)?

Re: What ORMs have taught me: just learn SQL (2014)

#335

Post by scarface74 »

ZenoArrow wrote: post #319
scarface74 wrote: post #292

Earlier quoted context omitted.

And then when you write "unit tests" for stored procedures with a lot of developers you get slow "unit tests" that don't scale across multiple developers because of Comte toon issues.

> "because of Comte toon issues" Qué?

Damn auto correct. That should have been "contention issues".

Re: What ORMs have taught me: just learn SQL (2014)

#337

Post by stcredzero »

zzzeek wrote: post #43

> If you're using an RDBMS, bite the bullet and learn SQL. If this person spent all that time using Hibernate and then SQLAlchemy, and all that time did not know SQL, then their suffering and bad experiences make complete sense. You absolutely need to know SQL if you're going to use an ORM effectively. Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating q…

you need to learn SQL first before you work with an ORM.

Analogously, I'd say that being able to write a compiler, down to having it generate machine code or assembly, gives you a leg up when using a compiled language. I've met and interviewed a number of coders who had cringeworthy gaps in their knowledge, because to them, a C compiler was just some kind of "magic."

Re: What ORMs have taught me: just learn SQL (2014)

#338

Post by needusername »

rickycook wrote: post #155
needusername wrote: post #139

Earlier quoted context omitted.

> providing abstraction for database-specific and driver-specific quirks That is quite theoretical. My PRs for fixing non-spec compliant behavior in pgjdbc get rejected because they might break some ORMs (mostly Play). My PRs for adding MariaDB sequence support to Hibernate get rejected because there are additional MariaDB features that Hibernate doesn't support as well.

it might be theoretical in hibernate, but sqlalchemy does a TON of this stuff as an example: https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalch... heaps of this kind of thing are nicely dotted around the code so you don’t have to deal with weird driver quirks, maps “Text” column type to whatever it needs to be in your given database to have an unbounded text blob id say that’s far more than theoretical EDIT…

In Java land the JDBC driver is supposed to do that. If it doesn't then that's a bug in the driver. If it's a bug in the JDBC driver then the fix needs to go into the JDBC driver, especially if the driver is on GitHub.

The presence of an ORM relying on these bugs should not prevent a bug in the driver from being fixed.

Re: What ORMs have taught me: just learn SQL (2014)

#339

Post by dorgo »

emeraldd wrote: post #271
jcadam wrote: post #258

Earlier quoted context omitted.

> ORM: You ask for something and because you've researched and found a well-written, quality ORM you trust that it will create a sane query. Ha. More like: ORM: You've just joined a project already using an ORM selected by an 'architect' that no longer works here. Everything is fine until you start testing your system with a database sufficiently populated with real-world data. You and the DBA spend the next next 6 m…

You have to known when to break free of the ORM. They are great for graphs of CRUD operations and pretty nasty for much of anything else. You may come to a different conclusion depending on the project and dataset of course.

And when you break free of the ORM prey to god that your ORM doesn't have a hidden cache somewhere. If it does then you spent a week tear out your hair until you figger out that the ORM' cache caused all the trouble.

Re: What ORMs have taught me: just learn SQL (2014)

#340

Post by zzzeek »

pjmlp wrote: post #214
scarface74 wrote: post #202

Earlier quoted context omitted.

So the easiest way to avoid using an ORM is to create your own ORM? What AI do you need? You map your tables to objects and relationships between objects via FK relationships.

I can get very creative with SELECTs, making use of Prolog style queries, which are fully done server side on the database. Most ORMs will download all the data and evaluate them on the client side, with code that is even more convoluted that the SQL one and thus with less performance.

> Most ORMs will download all the data and evaluate them on the client side

I've seen that pattern in lots of homegrown applications, but I've never seen such a thing in a mainstream ORM. Care to provide examples ?

Post reply on HN