I was working on a very database heavy PHP app about six months ago. All database access was done directly, with hardcoded SQL strings.
I'd suggested switching over to an ORM during the upcoming major verson's rewrite, and FINALLY got approval to start integrating one.
The next week I'm told that I need to trash all the code I'd just written, since the decision to use an orm has been reversed.

The rationale? According to management, ORMs aren't "scalable enough for our application" and would "reduce developer productivity". I pointed out that we would be processing ~10 concurrent operations, maximum; I was told that the technically details didn't matter and the person I was working under had the final say because they'd worked at IBM, briefly, as an intern.

I stopped working on that project about two weeks later, thankfully.

Id love to learn ORM but after hours of someone's explanation I still can't grasp it 😞

@linuxxx Not sure if you are ironic here.

Basically you have classes that represent the data of your databases. If you change data there it'll save the changes in the database. There are different ORMs out there that work differently but that's basically how they work.

@ctwx O.o. Is it that simple?!

@ctwx One question though, (no not ironic) how do you detect changes?

@linuxxx JavaEE does it somehow in the background. I guess it hooks into the assignment.

In Laravel (PHP) you have to call the save method. Or use methods that will call it for you. Let's take this:

$linuxxx = User::where('username', '=', 'Linuxxx')->first();
$linuxxx->name = 'super awesome';
$linuxxx->save();

The SQL queries are run by the ORM. 🙂

@ctwx Thanks!

@linuxxx you're welcome.

@linuxxx there's usually a .save() method.

@phexter Thanks and I've seen/made way too many of those 😅

ORM will not solve all your query problems. Some queries are so complex you wont be able to avoid hardcoding SQL

@payb4k that's true! But the vast majority of queries in this app were incredibly trivial.

Laravel's eloquent ORM is awesome to work with.

@phexter ORMs are actually intended to be used with relational databases, hence the name (object-relational mappers). NoSQL (document-based) databases can usually store application objects just as-is, given that they are serializable.

ORMs should be agnostic towards the used sql dialect, but their purpose is to easily store/retrieve entities and convert them into their respective relational/object representation.

@phexter 1/2
That's more or less the point - the object in your application has more or less the exact same representation in your NoSQL database (let's stick to document stores for now) as it has in your application.

It is stored and retrieved as it is, where as in a relational database it's usually split out across multiple tables. An ORM collects the information from those different tables and gives you back a coherent object as defined in your application.

Now I know that in reality things are not that black and white, and you usually end up with some sort of implicit schema and relations/dependencies between your documents in your NoSQL database, but it is still a completely different concept than the relational one.

Additionally, there are no referential integrity checks and (mostly) no transaction support in NoSQL-based systems, and even if so, they work in a drastically different way than in RDBMSs.

@phexter 2/2
Adding support for NoSQL DBs and still providing a generic interface to the user adds such an amount of complexity to the implementation that I think most ORMs are right to dismiss that sort of feature.

If you want/need that kind of functionality, there are ODMs (Object-Document Mappers) for NoSQL systems such as Mongoose - but they then usually require you to work with a certain schema, which imo raises the question if you shouldn't have used an RDBMS in the first place.