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)

wozniak.ca

Post reply on HN
Print view View original

141–150 of 305 posts

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

#141

Post by Bahamut »

toast0 wrote: post #121
StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

> 2. If you're not using an ORM, then you ultimately end up writing one. And doing a far worse job than the people who focus on that for a living. It's no different from people who "don't need a web framework", and then go on to re-implement half of Rails or Spring (without accounting for any CSRF protection). Learning any framework at a professional level is a serious time investment, and many student beginners or q…

I'm currently at a company that is not using an ORM - what has happened is that developers have written endpoints with inconsistent data formatting for similar data types, which prevents the possibility of creating abstractions cleanly on the client. It would have been nice to have a lightweight ORM, if only for object consistency.

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

#142

Post by cmrdporcupine »

teacup50 wrote: post #65
StevePerkins wrote: post #34

Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at yo…

> If you're not using an ORM, then you ultimately end up writing one. Only if you assume that Object Relational Mapping is the only way to express type checked database access at the application layer. ORMs are broken by design; there's no lossless bridge between relational theory and OO -- only inconsistent, error-prone, complex approximations. Instead of bringing relational theory to the programming language, ORMs…

Yep, for years my bias has been trending to the relational method of modeling data rather than the object oriented way.

The relational model is more flexible -- you can slice data up in any number of ways, rather than through a fixed hierarchy.

The relational model was developed by Date/Codd to address the needless complexity and brittle nature applications built around network or hierarchical databases of the 60s/70s, which are in many ways analogous to today's OO relationships.

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

#143

Post by nostrademons »

dkarapetyan wrote: post #48

Never seen a large enough project that relies on an ORM be anything other than a giant mess. I mean never. The conclusion is correct. From an application perspective the db is just another API and should be treated that way and the ORM should just be thought of as a convenient DSL for creating queries on top of that API.

To be fair, I've never seen a large project be anything other than a giant mess. This is the nature of large projects. If it's not a giant mess, you are probably leaving user happiness (= $$$) on the table.

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

#144

Post by CuriousSkeptic »

manigandham wrote: post #135

Not this again. Why is this coming up at all in 2016? There isn't even a valid debate here. ORMs are a tool, that's it. The relational operations of SQL and the object-oriented (or functional) logic of your application code are usually very different and it's nice to have a mapper that lets you interact with your app's language while it takes cares of automatically mapping it to SQL. For 99% of database ops where it'…

My experience with hibernate, entity framework, nhibernate, and lastly dapper has basically left me thinking Dapper is all you'll ever want. I can't imagine a use case where I'd rather opt for NHibernate or EF at the moment.

(I might add, Dapper in combination with C#6 even gives me enough type saftey to be happy. String interpolation and the nameof operator complements dappers DTO approach nicely)

Since you seem to have similar experiences Im curious. When would you ditch dapper for the others?

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

#145

Post by intrasight »

PeCaN wrote: post #119
craigvn wrote: post #98

Earlier quoted context omitted.

But once you have run the stored proc how do you display it to the user? How do you get the data from the UI to the stored proc to execute? You write some code or it happens by magic? If you write some code, then you have just written an ORM.

> If you write some code, then you have just written an ORM. What? No, I've written code to query a database. Not an Object-Relational Mapper. my $q = $db->prepare("get_my_stuff_by_name(?);"); $q->execute($name); or with fancy metaprogramming: use DBMagicStuff 'postgres://…'; get_my_stuff_by_name($name); That's not really an ORM.

You are both partially right. An ORM deals with the black magic of connections, parameters, transactions, etc. If you don't use an ORM, then you still have to deal with those semantics. But I do agree that you aren't writing an ORM.

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

#146

Post by intrasight »

ZanyProgrammer wrote: post #131
maxxxxx wrote: post #75

Earlier quoted context omitted.

I think if they were better integrated with the IDE and easier to debug then they would probably write better stored procedures.

As a C# dev myself, fuck stored procedures, to be quite honest.

Please elaborate

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

#147

Post by intrasight »

tfigment wrote: post #6

I written a fair number of C# LOB apps and use LINQ quite a bit with mysql. I don't even want to talk about Java and some of its ORMs as its too painful to think about. I agree with the sentiment of the post but in compiled languages I really want an ORM to simplify unpacking result sets. LINQ is great when it works but joins sort of suck as well as calling in-built sql functions and it can some times generate highly…

unpack result sets into what?

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

#148

Post by dkarapetyan »

nostrademons wrote: post #143
dkarapetyan wrote: post #48

Never seen a large enough project that relies on an ORM be anything other than a giant mess. I mean never. The conclusion is correct. From an application perspective the db is just another API and should be treated that way and the ORM should just be thought of as a convenient DSL for creating queries on top of that API.

To be fair, I've never seen a large project be anything other than a giant mess. This is the nature of large projects. If it's not a giant mess, you are probably leaving user happiness (= $$$) on the table.

And it comes at the expense of craftsmanship and programmer happiness. Lately I've been thinking how much initial architecture affects the mental well-being of all subsequent programmers that join the project. This is one of the reasons there is such a high turn-over and burnout rate in programming. If you're not consistently paying back technical debt and improving the architecture of the project then you're paying for it in other ways with the revolving door of programmers.

Then again if you're a big enough business it probably doesn't matter as long as customers are paying you. All you have to do is plug-in another cog/programmer into the machine when the previous one wears out.

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

#149

Post by intrasight »

prodigal_erik wrote: post #25
vrdabomb5717 wrote: post #13

Earlier quoted context omitted.

At the big tech firm I work at, there's a best practice where any database (whether that's a traditional RDBMS or a NoSQL client) is abstracted away by a microservice with a defined API, and every other application that wants to get that data needs to interact with the microservice. That way, the database schema can change without it affecting multiple applications. There's still the traditional mismatch between ORM…

We have decades of research into filtering, joining, and aggregating across a complex set of tables and views. With microservices you have to roll your own query planning and stream all the intermediate results on the wire even when you're throwing away most of them.

That probably is true - if you have a crappy API design
Post reply on HN