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

171–180 of 360 posts

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

#171

Post by blaisio »

zkomp wrote: post #163
blaisio wrote: post #151

Earlier quoted context omitted.

I mean, stored procedures are fine, but I don't think that actually solves anything? Except maybe for reducing the amount of SQL code you have to send back and forth and (in some databases) allowing for a few more optimizations? If you use stored procedures, all you've done is move part of the model into the database, so you have to update the stored procedures as part of a deployment. You still need to have the SQL…

you solved isolation decoupled much of the db logic from app-logic and made security easier you can deploy schema changes independently you can change everything and the app should not notice

But you can decouple the database logic from the app logic anyway, without using stored procedures. They don't actually help you do this since you still need code that knows what stored procedures to call. Also, I'm not sure how this makes security easier? It seems like security would be the same or maybe a little harder since you now have to track the stored procedures you're currently using as well.

I'm not really sure what you mean by "you can deploy schema changes independently" and "you can change everything and the app should not notice". The stored procedures are basically just an extension of the apps logic right? So you can deploy them at any time, sure, but that isn't different from an app that doesn't use stored procedures, because you could also deploy changes to any part of that app at any time.

I do think stored procedures can be more efficient, because you have a lot more control. But it's not like they are clearly superior from an organizational standpoint. If you write an ORM using stored procedures, it's still an ORM.

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

#172

Post by tnolet »

westurner wrote: post #87

ORMs: - Are maintainable by a team. "Oh, because that seemed faster at the time." - Are unit tested: eventually we end up creating at least structs or objects anyway, and then that needs to be the same everywhere, and then the abstraction is wrong because "everything should just be functional like SQL" until we need to decide what you called "the_initializer2". - Can make it very easy to create maintainable test fixt…

Objection.js and the Knex query builder are excellent. Think ORM light with full access to SQL.

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

#173

Post by zkomp »

blaisio wrote: post #171
zkomp wrote: post #163

Earlier quoted context omitted.

you solved isolation decoupled much of the db logic from app-logic and made security easier you can deploy schema changes independently you can change everything and the app should not notice

But you can decouple the database logic from the app logic anyway, without using stored procedures. They don't actually help you do this since you still need code that knows what stored procedures to call. Also, I'm not sure how this makes security easier? It seems like security would be the same or maybe a little harder since you now have to track the stored procedures you're currently using as well. I'm not really…

As far as I know, in my experience. Stored procedures in postgres are good when you really use the database and care about the data, you need transactions, need to handle races and concurrency etc. Whereas ORMs break down at this point or prevent you even getting to a point when you can use your database as a database.

Why pretend your SQL database is about objects? It is not... (it is about data)

A stored procedure can act like a view or a query, or use procedural logic. Point is: your app can call it and get a concistent result, no matter what refactoring has been going on.

A direct query needs to know too much about the database (orm generated or otherwise) which prevent refactoring and couples app to database harder...

You can rename or merge tables, views functions in the database but the interface the app use (stored procedures/DAL) will stay the same and work the same way.

As for app logic... I prefer bussiness logic in the database, not the app when the data is important. Application logic stay in your application, data dependent bussiness logic stay with the data.

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

#174

Post by emilsedgh »

avmich wrote: post #107
erikpukinskis wrote: post #79

Earlier quoted context omitted.

Ok, let’s break this down: > Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating query composition, providing abstraction for database-specific and driver-specific quirks None of that requires an ORM. A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. > providing patterns to map object graphs to…

> A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. What's the difference? To me, an ORM is largely a query builder.

ORM: You ask for something and you don't care _how_ its fetched.

Query Builder: You build a query, just not in SQL. So you can get around SQL's limitations (like composition)

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

#175

Post by Animats »

avmich wrote: post #107
erikpukinskis wrote: post #79

Earlier quoted context omitted.

Ok, let’s break this down: > Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating query composition, providing abstraction for database-specific and driver-specific quirks None of that requires an ORM. A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. > providing patterns to map object graphs to…

> A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. What's the difference? To me, an ORM is largely a query builder.

ORMs are more useful as insert builders. Putting data from an object into the database is something of a boilerplate process. Queries vary with what you want to ask. Most of the time, you don't need all the fields, so filling up some object just because it has slots for everything is a waste of effort. Especially if it means references to multiple tables.

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

#176

Post by petre »

avmich wrote: post #107
erikpukinskis wrote: post #79

Earlier quoted context omitted.

Ok, let’s break this down: > Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating query composition, providing abstraction for database-specific and driver-specific quirks None of that requires an ORM. A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. > providing patterns to map object graphs to…

> A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. What's the difference? To me, an ORM is largely a query builder.

A query builder aids you at constructing queries, while an ORM builds queries for you, runs them and maps the output to objects. It's more sophisticated than a query builder.

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

#177

Post by andybak »

emilsedgh wrote: post #174
avmich wrote: post #107

Earlier quoted context omitted.

> A simple query builder will suffice and it will be much easier to debug and much less error prone than an ORM. What's the difference? To me, an ORM is largely a query builder.

ORM: You ask for something and you don't care _how_ its fetched. Query Builder: You build a query, just not in SQL. So you can get around SQL's limitations (like composition)

> ORM: You ask for something and you don't care _how_ its fetched.

Try this:

> 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.

or possibly:

> ORM: You ask for something and you accept the tradeoffs vs hand-written queries but you're content that it's the correct tradeoff for your use-case.

There's plenty of places for bottlenecks to hide and premature optimization is the root of at least some evils.

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

#178

Post by andybak »

exclusiv wrote: post #74
alexandercrohde wrote: post #61

Earlier quoted context omitted.

I think there are 3 main reasons ORMs came into common use: 1. As a reaction to common SQL injection from poor libraries not implementing parameterized queries. (2004 or so) 2. Novice engineers not wanting to learn SQL (look I learned how to make a blog in RoR, and I like mongo!) 3. As a theoretical abstraction above the data-store (as though you might someday be able to switch the data-store beneath the ORM) 1 has b…

I'd add #4 - it's just generally faster and more enjoyable to develop with a good ORM.

Yep. Learned SQL. Happy never to have to touch it again.

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

#179

Post by andybak »

Like static vs dynamic typing and frameworks vs libraries this is an endless debate that rarely sheds much light on the topic.

The people who use ORMs daily are likely to favour them and those that think they are the devil's work are unlikely to have intimate experience of a range of different ORMs.

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

#180

Post by spronkey »

default-kramer wrote: post #54
jmadsen wrote: post #47

An ORM is not a "query builder" An ORM turns your result into a collection of objects. THAT is what an ORM is for and about. The fact that they are built on top of query builders and lighten the load when developing is just a handy side effect.

To me, it hinges on what you mean by "a collection of objects." If it is just a list C-like structs, that's great. If it involves lazy-loaded child collections, inheritance hierarchies, or any kind of behavior at all, that makes me worried.

Yeah, I agree. Lazy loading in ORMs what happens when people want OO databases. And by OO databases, I mean everything to act like it's in an in-memory collection.

Sounds nice, but in reality, latencies, networks, massive data sets, atomicity of operations, and a whole host of other annoyances get in the way.

... so it ends up being simpler and easier in the long run to be very explicit about your interactions with data stores. Took me a long time to get to this point.

Post reply on HN