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.