Hacker News Reader

Comment by eberfreitas | Hacker News Reader

  > Moreover, the fact that Django makes most of the decisions about how the database will be structured just baffled me – why does Django know better than me what the database should look like?

If that is really true (I don't have any Django/Python experience) the simple answer is "It doesn't". In the long run, relying on the ORM to provide high scalability is not a sane choice and I'm pretty sure Django must be able to allow some flexibility on how tables and columns are defined according to your needs.

The thing is that lately I'm finding myself unhappy with the idea of ORMs and how they handle things. When I see that a framework has a lot of dependency to some ORM, I get instantly unmotivated to learn more about it.

View on HN

Here, here!

ORMs seem to be great if you are doing prototyping, but most of my analysis tools have to be built against existing datasets or ecosystems. I'm either shoehorning in two databases from two separate architectures together or at the very least working with one that is populated by another tool.

ORMs fall flat on their face in these circumstances, and I'm left with having to fight against it in cases where it may be tightly coupled.

One of the biggest problems I have had with a lot of the cool new frameworks is that they make basic assumptions about how they will use them.

I don't completely understand the idea that ORM's are not scaleable. All they are is an abstraction layer that makes your life as a dev easier. With Active Record, Rail's ORM, I can do anything I would want to do with it. Just because you are not creating the database in SQL doesn't mean that you can't do complex things.

in my experience the general sentiment is that the ORM is a leaky abstraction because it's common to make performance decisions based on the ORM's peculiarities.

up to a certain size, most ORMs will behave just fine! the bigger problem is when your mental model of how the ORM should be behaving for a certain data access pattern is thwarted by the actual implementation. This usually only happens when you notice a performance bottleneck around a semi-exotic query that you know to be trivial in sql or whatever.

it's also possible to put up performance abstractions between you and that ORM bottleneck, but often the experience and tradeoff sours most people. i don't blame them, but i agree that for most day-to-day cases, orms are pretty handy.

"If your app is simple enough, you don't need an ORM. If you think your app is complex enough to use an ORM, it probably doesn't do much good."

I still find myself doing `for p in Person.objects.raw('SELECT * FROM myapp_person'):`...

Source please?

Source: I'm a developer. :-|

"If you want to sound credible, wrap it in quotes."

-- Me, a developer.

Reply on news.ycombinator.com