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

221–230 of 305 posts

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

#221

Post by int_19h »

thomasahle wrote: post #52
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…

> An ORM provides type checking at your application layer This. When composing complex queries, we really want type checking and SQL injection safety.

The problem is that doing queries over relational databases in a type-safe way requires either 1) some form of structural typing (for projections), or 2) ignoring projections altogether, which brings a slew of perf problems to the table.

Ironically, this means that OCaml is probably the best [reasonably popular] language to use an ORM in.

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

#222

Post by collyw »

btilly wrote: post #185
peschkaj wrote: post #169

Earlier quoted context omitted.

I've yet to see empirical proof that stored procedures don't scale well. If you write an application in your SQL dialect of choice, that likely won't scale well, but putting data access behind an API should scale well no matter if that API is in Rails, Spring, or a stored procedure.

I don't know what you consider "empirical proof", but it seems obvious to me. And should be obvious to anyone competent who has ever had to scale stuff. A system fails to scale when it has a bottleneck, and that bottleneck gets overwhelmed. You make it scale better by scaling the bottleneck, which can be done by moving work out of the bottleneck, or by parallelizing it in some way. The natural bottleneck for any syst…

The database is usually the bottleneck because of IO, not because of load on the actual database in my experience. Assuming you know how to design and index a database.

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

#223

Post by collyw »

PeCaN wrote: post #120
Udik wrote: post #115

Earlier quoted context omitted.

Don't know about the parent, but I always felt that stored procedures end up by incorporating a good share of the business logic, extracting it from the main code of the application. This creates a messy situation in which you have your business logic split up between two completely separate and different systems, one of which (the stored procedures) is much harder to read, write, maintain and test. That said, I also…

It's fat models vs thin models, just with fat database vs thin database. You have to be careful.

I am working on an app where the original developer has followed a "thin models fat controllers philosophy". I have never seen this referred to as a good thing anywhere else (and Django works far better the other way around). Is there any information on why this might be a good idea / benefits to this approach?

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

#224

Post by Udik »

spacecowboy_lon wrote: post #208
Udik wrote: post #115

Earlier quoted context omitted.

Don't know about the parent, but I always felt that stored procedures end up by incorporating a good share of the business logic, extracting it from the main code of the application. This creates a messy situation in which you have your business logic split up between two completely separate and different systems, one of which (the stored procedures) is much harder to read, write, maintain and test. That said, I also…

That is normally considered a good thing other wise different applications accessing the same data have to roll there own - do you really want multiple versions of biz logic. eg a large organizations like a bit telco may have multiple applications that update customer records.

Should they do that through a single service api instead of directly hitting the database?

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

#225

Post by int_19h »

teacup50 wrote: post #184
chowells wrote: post #166

Earlier quoted context omitted.

Haskell does OO just fine. It doesn't do nominal subtyping, but that's really a misfeature in OO anyway. That said, persistent doesn't do OO.

Data encapsulation (e.g. via ADTs) does not equal "OO".

I would argue that OO is polymorphism + innate object identity. Though the latter only matters if you have mutability; but then, whether OO without mutability is "true OO" is one of those deeply philosophical questions.

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

#226

Post by dkarapetyan »

lmm wrote: post #213
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.

I've worked on a 400kloc Java system that was beautiful in the half that used Hibernate, and horrific in the half that didn't.

400kloc Java. That's cute. Not saying that's not impressive. The scales I've seen you're off by a few orders of magnitude.

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

#227

Post by danpalmer »

Retra wrote: post #193
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…

One of the problems with learning a web framework is that there are a lot of them, and the effort it takes to find out which one best serves your needs can seem to be on par with rolling your own, without the assurance that you'll actually get your needs met. And I suppose the ORM issue faces the same decision-making problem. Hand-rolled crap is at least crap that was rolled to suit the problem you're facing, and you…

I see learning a framework as less about trying to get all the things you need, and more about 'borrowing' someone elses architectural thinking. When you encounter something the framework doesn't provide, you probably have all the architectural tools available to you to create something good that fits in well with the rest of the framework. Also, when you need to move to another framework, you have a base of experience you can draw from to help you learn much faster.

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

#228

Post by DougBTX »

manigandham wrote: post #139
mixedCase wrote: post #137

Earlier quoted context omitted.

You could argue that anything that interfaces with a database is an ORM, but it is certainly no ORM in the Hibernate/ActiveRecord/EntityFramework sense. It does very little "magic" and you're in full control of the SQL from the start.

Sure, let's say an ORM is anything capable of turning normal app code into SQL statements by itself. What do ORMs do that's magic? What are the problems? Are you not in full control of them? It's your code after all that's using them. I really don't get how they suddenly force any issues on you that you don't create yourself. The output SQL doesn't really matter if it gets the job done, and in cases it does you still…

Thanks for these questions. Initially it wasn't clear to me what the difference was either, but now I understand the distinction a little more.

The ORMs discussed in the article map a whole object model to a whole relational model. The idea is that a single piece of primitive data, say a bool flag on an entity, will have one location in the relational model, and one location in the object model, and the mapper's job is to get the data from one to the other and back again.

Hibernate will guarantee things about the object model, for example within a particular session, the entity A which maps to a record with id 1 in the database will be represented by the same object instance, so even if A is referenced indirectly through two different routes, eg, obj.foo.a and obj.bar.a, it would reference the same instance of A. The instance will only be fetched once, can be mutated through either route, and then saved back to the database using the mapping.

That's the sort of thing which is possible with a single mapping, but the abstraction breaks down outside that mapping. For example, questions like this on StackOverflow:

http://stackoverflow.com/questions/2470129/how-can-one-fetch...

He wants to select part of a database record, not the whole record. The mapping will only be defined for whole entities, so he has to use the complex projection syntax instead of a normal fetch. The top answer suggests mapping the data into a User object anyway, which will result in his code having some User objects will all their properties set, and some with just a subset.

This puts pressure on the programmer to stick to the single mapping. Partial fetches like this could lead to an object which represents a particular user which may or may not still be the same instance, and it may or may not support being saved back into the database.

> Are you not in full control of them?

So, yes, you are in full control, but the benefits come when there is a single mapping between the relational model and the object model. In practice, there isn't a single object model, let alone a single mapping.

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

#229

Post by int_19h »

lmm wrote: post #205
teacup50 wrote: post #65

Earlier quoted context omitted.

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

More like relational databases are outdated. There was one truly committed effort to bring the database model into the programming language - EJB - and there's a reason it's now a curse word. The successful systems of the past ten years have been those that moved away from the relational model, using simple datastores controlled by application code.

I'd bet that there is more code written in the past 10 years that uses SQL, than that which uses "simple datastores". You don't hear it much, because it just works, all the problems are well known (and so are the various solutions & workarounds), and so it's boring. Whereas, "Company X has adopted No-SQL solution Y for its project Z! That means it works!" makes headlines.

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

#230

Post by lmm »

dkarapetyan wrote: post #226
lmm wrote: post #213

Earlier quoted context omitted.

I've worked on a 400kloc Java system that was beautiful in the half that used Hibernate, and horrific in the half that didn't.

400kloc Java. That's cute. Not saying that's not impressive. The scales I've seen you're off by a few orders of magnitude.

Oh sure, it's not the largest system I've worked on by any means, it just seemed relevant because at the time I was working on it it was almost exactly a 50/50 split between the hibernate parts and the not. And honestly I find beyond a certain size the techniques you have to use are pretty similar - there's very little practical difference between working on a 400kloc and a 4mloc project.
Post reply on HN